[haiku-gsoc] Re: XSI semaphore implamentation patch #2
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Wed, 30 Jul 2008 14:48:44 +0200
On 2008-07-30 at 02:01:47 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
wrote:
> 2008/7/29 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >> Because as I said, the performance issues happens only on process exit
> >> and
> >> from
> >> an user point of view it shouldn't be a problem.
> >
> > Not sure what to say. You wrote yourself in your previous mail that SETVAL
> > and SETALL are affected (BTW, the latter is even very suboptimally
> > implemented and thus O(m*n) with m = number of sems in the set and n =
> > total
> > number of undo entries). And as I wrote in my previous mail RMID should be
> > affected in the same way. So the performance issues when a lot of
> > semaphores
> > are used are definitely not limited to program exit only.
>
> Exactly. It also affect the performances of initialization, as that's
> what SETVAL and
> SETALL are. Theorically during inizialization there won't be any
> process waiting on
> it, nor there be a sem_undo request queued.
>
> The other design I started with, required a private list in every
> XsiSemaphore, so that
> when SETALL or SETVAL was called, all it has to do was iterate through
> the list and
> set the sem_undo value to zero. Despite improving the inizialization
> performance, it
> would also require to add another list to the team to keep an object
> per semaphore
> used with SEM_UNDO. This list would be accessed at exit time in the
> very same manner
> the XsiSemaphore private one is. This design though, add the
> complexity of keeping the
> two list synchronized, plus something else I don't recall right now
Managing too lists is not really more complex than managing one list and a
counter. You basically have to replace the counter increments/decrements by
list adds/removes. The only additional complexity is the per team structure,
but that is needed anyway to keep track of private semaphore sets, that
should be deleted on team exit/exec*().
I would go with an undo entry per semaphore set and team, BTW.
> Anyway, I decided to choose semplicity as I though that the
> performances lost on exit
> and initialization won't be a big problem. Theorically there won't
> even be a process with
> requested sem_undo at inizialization, as theorically, SETVAL and
> SETALL are the very
> first operation done on a set.
It doesn't make a difference when SETVAL/SETALL are called or whether there
are undo entries for these semaphores, since you unconditionally iterate
through the whole global undo entry list in any case.
CU, Ingo
Other related posts:
