[haiku-gsoc] Re: [HCD]: xsi semaphore - kernel side
- From: "Salvatore Benedetto" <emitrax@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Tue, 17 Jun 2008 22:10:43 +0000
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.
Then each sem_object should have it's own queue of threads object.
Regards,
--
Salvatore Benedetto (a.k.a. emitrax)
Student of Computer Engineer
University of Pisa
www.haiku-os.it
Other related posts:
