[haiku-gsoc] Re: [HCD]: xsi semaphore - kernel side
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Wed, 18 Jun 2008 01:26:49 +0200
On 2008-06-18 at 00:10:43 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
wrote:
> 2008/6/17 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >
> > On 2008-06-17 at 18:21:20 [+0200], Salvatore Benedetto <emitrax@xxxxxxxxx>
> > wrote:
> >> 2008/6/15 Ingo Weinhold <ingo_weinhold@xxxxxx>:
> >> >
> >> > On 2008-06-15 at 23:26:45 [+0200], Salvatore Benedetto
> >> > <emitrax@xxxxxxxxx>
> >> > wrote:
> >> >>
> >> >> time for me to use this mailing list.
> >> >>
> >> >> I'm looking at the current implementation of haiku semaphore and I see
> >> >> that
> >> >> during boot a few pages, it depends on the number of semaphore, is
> >> >> allocated
> >> >> in order to store semaphore slots. I guess for performances reason.
> >> >>
> >> >> Now I'm wondering if I should do the same for the xsi semaphore, even
> >> >> though
> >> >> only ported application (currently none) will used it, or create them
> >> >> run
> >> >> time
> >> >> when I needed? The latter would avoid waisting a few MB of probably
> >> >> unneeded memory
> >> >> when xsi semaphore are not used.
> >> >
> >> > Please just use a hash table (key_t -> semaphore object).
> >>
> >> Ok. The only thing I haven't understand with the standard yet though,
> >> is whether the key_t table
> >> should be shared among IPC primitives (semaphore, message queue, shared
> >> memory)
> >> or if I have to declare one for each primitives.
> >
> > I haven't seen the standard mentioning anything in this regard, so I'd use
> > separate hash tables.
>
> Ok, so a first structure should be
>
> key_t object;
> vector<sem_object> sems;
>
> as if I understood correctly, one can create and associate to a single
> key a set of semaphores.
Yep. Please don't use STL vector though, but a simple array.
> Then each sem_object should have it's own queue of threads object.
Exactly. And semop() needs to allocate an array of such queue entries (one
for each semaphore to wait on).
You'll also have to consider locking. You could have a mutex per semaphore
set or just reuse one of the global mutexes (you need one or two for the hash
tables).
Apropos hash tables, I just re-read the sem*() operations and it looks like
you need two hash tables. One mapping key_t -> int (IPC keys to semaphore
IDs) and the second one mapping int -> semaphore set object. Private
semaphores obviously wouldn't be entered in the first table.
CU, Ingo
Other related posts:
