bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: POSIX semaphore for GNU/Hurd


From: Gaël Le Mignot
Subject: Re: POSIX semaphore for GNU/Hurd
Date: Sun, 27 Oct 2002 20:10:24 +0100
User-agent: Gnus/5.090008 (Oort Gnus v0.08) Emacs/21.2 (i386-pc-linux-gnu)

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" - kilobug@freesurf.fr - 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]