[haiku-gsoc] Re: [HCD]: xsi semaphore - kernel side
- From: "Salvatore Benedetto" <emitrax@xxxxxxxxx>
- To: haiku-gsoc@xxxxxxxxxxxxx
- Date: Fri, 20 Jun 2008 23:06:07 +0000
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:
