[haiku-gsoc] Re: [HCD]: xsi semaphore - kernel side

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

I think I'll go for one mutex per set.

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

Yes, and here it the data structure I intend to use.

* Hash table sIPCTableSem {sIPCTableMsg, sIPCTableShm}
key_t ipcKey
int sem_set_id {msg_queue_id, shm_memory_id}

* Hash table sXSISemaphoreSet
int semaphore_set_id;
ipc_perm permission;
time sem_otime
time sem_ctime
int nsems
lock mutex
vector<xsi_sem> semaphores

The above are all information related to the whole set.
Note: The position in the vector represent the number of the semaphore,
I don't think it's necessary to add such an information to the below structure
since a user cannot delete a single semaphore, but only the whole set.

* xsi_sem structure
short semval
pid_t sempid
short semncnt
short semzcnt
list<threads> waitingToIncrease
list<threads> waitingToBeZero

The above are all information about a single sem.

Variables name will probably be different.

Any comments?

BTW: Are hash tables thread safe or do I have to use an explicit lock ?

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

Other related posts: