[haiku-gsoc] Re: XSI semaphore implamentation patch #2

2008/7/30 Ingo Weinhold <ingo_weinhold@xxxxxx>:
>
> 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.

Hmm...  Let's say I use the following structure, and you agree :-)

struct undoRequest : DoublyLinkedList<undoRequest> {
     union {
          team *team;  // Used in the sem list
          XsiSemaphoreSet *semaphore_set; // Used in the team
     } p;
     short  undo_value;
     int      semaphore_number;
}

First of all, everytime there is an undo request you have to create two very
same structure and add it to both list (team and sem set). But that could be ok.

When either SETVAL/SETALL or RMID is called, you have to invalidate
the undo_request of the team. Standard says to set to zero the undo_value on SET
call, but I'd say to just remove the request as in the RMID case. So, everytime
the object is removed from the semaphore set list, the object of the
same request
has to be removed, or at least invalidate, from the team list and
that's require to iterate through
the list which can contain other semaphore set undo request (although you could
say that it contains less objects than the global undo list I use
now). But still, you
are required to iterated through two list to remove one request.

The reason the team request has to be removed is that, in worst case
scenario, the semaphore
set id, can be reused, and other sem_undo request can be added to it meanwhile,
so you won't know if the team undo request is still valid or not. Thus
the need of removing
it.

Same thing happens, more or less, when the team exit. The semaphore
set undo request
must be removed, which requires to iterate through it's list (although
the same observation
of having less requests of the current global undo request can be applied).

>
>> 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.

Exactly. And that can be easily fixed with a counter in the set.

Seriously, I understand your concern about perfomances and I don't mean
in any way to waist your time, but I thought optimization in this situation
could be postponed.

Anyway, if the way I explained above with the two list is what you had
in mind, I don't
have problem implementing it. Otherwise hints are accepted :-)


>
> CU, Ingo
>
>

Regards,
-- 
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it

Other related posts: