[fpc-devel] Patch for RTLEvent calls which fixes a race condition

[Lloyd Park]

But my patch fixes the problem.  In researching the problem I found a
pthreads tutorial that said if you are using pthread_cond_wait()
outside the body of an if statement, you are probably not using it
properly.  So my patch adds a boolean named IsSet to the intRTLEvent
record.  It is only set, reset, or tested  inside the mutex
lock/unlock blocks.  RTLEventSetEvent sets the boolean.
RTLEventWaitFor calls pthread_cond_wait() if IsSet is false.  After
that RTLEventWaitFor clears the IsSet boolean.

The result is if one thread calls RTLEventSetEvent() and later another
calls RTLEventStartWait the second threads call to  RTLEventWaitFor
will not wait.  But if the order is reversed, the calls work like they
did in the past.

On 12/15/06, Micha Nelissen <micha at neli.hopto.org> wrote:
> Lloyd Park wrote:
> > I had problems with a threaded app under Linux which hung because one
> > thread would sometimes call RTLSetEvent before the other called
> > RTLEventStartWait.  The attached patch for the 2.1.1 branch revision
> > 5606 fixes the problem.
>
> Better rewrite it to use semaphore (sem_*) functions. The conditional
> variables are very disappointing (exactly for the reason you describe).
>
> Micha
> _______________________________________________
> fpc-devel maillist  -  fpc-devel at lists.freepascal.org
> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>