On Tuesday 17 October 2006 09:03, Jonas Maebe wrote: > On 17 okt 2006, at 10:44, Daniël Mantione wrote: > > procedure intRTLEventSetEvent(AEvent: PRTLEvent); > > var p:pintrtlevent; > > > > begin > > p:=pintrtlevent(aevent); > > pthread_mutex_lock(@p^.mutex); > > pthread_cond_signal(@p^.condvar); > > pthread_mutex_unlock(@p^.mutex); > > end; > > > > procedure intRTLEventStartWait(AEvent: PRTLEvent); > > var p:pintrtlevent; > > > > begin > > p:=pintrtlevent(aevent); > > pthread_mutex_lock(@p^.mutex); > > end; > > > > procedure intRTLEventWaitFor(AEvent: PRTLEvent); > > var p:pintrtlevent; > > > > begin > > p:=pintrtlevent(aevent); > > pthread_cond_wait(@p^.condvar, @p^.mutex); > > pthread_mutex_unlock(@p^.mutex); > > end; > > This last pthread_mutex_unlock does not make sense to me. From the > pthread_cond_wait man page: > > The pthread_cond_wait() function atomically unlocks the mutex > argument > and waits on the cond argument. > > So the mutex should already be unlocked afterwards.
If you would have read a couple of lines further you also would have found: |Before returning to the calling thread, pthread_cond_wait re-acquires |mutex (as per pthread_lock_mutex). > Further, what is > the lock/unlock for in the intRTLEventSetEvent? pthread_cond_signal > can perfectly deal with multiple threads simultaneously signalling > the same condition variable (pthreads is a multithreading api, not a > random non-reentrant piece of code). Oh, is it? Read the f*cking man page: |A condition variable must always be associated with a mutex, to avoid |the race condition where a thread prepares to wait on a condition |variable and another thread signals the condition just before the first |thread actually waits on it. Vinzent. _______________________________________________ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel