Sun, 27 Oct 2002 10:57:08 -0800 (PST), tu as dit :
>> Hello,
>>
>> While trying to compile abiword, and so gnome-vfs, on GNU/Hurd, I've
>> seen that it uses POSIX semaphore, that we don't implement yet.>
>> So, I've done an implementation of POSIX semaphores using a pthread_mutex
>> and a pthread_cond. I didn't test it yet, but it compiles, and I'm pretty
>> confident in it (but I'm sure of the correct behavior of the destroy
>> function if some threads are locked on the semaphore).
> Thanks for this work, did you compile it with -Wall?
I included it in libpthreads and built it with the Hurd, so yes.
>> /* Initialize the semaphore and set the initial value - as in LinuxThreads
>> pshared must be zero right now. */
>> int
>> sem_init (sem_t *sem, int pshared, unsigned int value)
>> {
>> if (pshared)
>> return -1;
> If you wanted to be consistant with LinuxThreads this should be
> if (pshared)
> {
> errno = ENOSYS;
> return -1;
> }
I know we should do that, but
> However, I think it would be better to actually implement this feature.
That would be far harder to do.
>> pthread_mutex_unlock (&sem->count_lock);
> Why is there an unlock here? while (1) is an infinite loop so this line
> should not be reached. Although,
that's sure
> while (!(sem->count))
> pthread_cond_wait (&sem->lock, &sem->count_lock);
sem-> count--;
> pthread_mutex_unlock (&sem->count_lock);
> return 0;
> would be shorter.
yes, true, I just didn't think of it; at the beginning I locked and unlocked
the mutex in the loop, and then I realized that it was not usefull, so I
moved both call outside the loop without thinking of further optimizations.
> The real question is, are either of these implementations
> cancellable? As far as I can tell both are because pthread_cond_wait is
> cancellable.
I'm not sure of what exactly should happen.
--
Gael Le Mignot "Kilobug" - [EMAIL PROTECTED] - http://kilobug.free.fr
GSM : 06.71.47.18.22 (in France) ICQ UIN : 7299959
Fingerprint : 1F2C 9804 7505 79DF 95E6 7323 B66B F67B 7103 C5DA
Member of HurdFr: http://hurdfr.org - The GNU Hurd: http://hurd.gnu.org
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
