[fpc-devel] Threads and alot of crap

[Vinzent Hoefler]

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.