[fpc-pascal] Semaphore problems

Vinzent Höfler JeLlyFish.software at gmx.net
Mon Jul 24 22:05:34 CEST 2006

Burkhard Carstens wrote:
> Am Montag, 24. Juli 2006 20:33 schrieb Vinzent Höfler:
>> Burkhard Carstens wrote:
>>> [..]
>>>> ... As long as rtlevent is used with this
>>>> in mind, it should give a consistent behaviour on windows and
>>>> linux.
>>> "this in mind" means: The only way how rtlevent should be used is:
>>> 1. call rtlstartwait
>>> 2. start the code (e.g. start/resume a thread), that signals the
>>> event.
 >>> 3. call rtlwaitevent
>> Great. ;( But there's a flaw in this: If I'd actually know that
>> thread A had been executed rtlstartwait() before thread B tries
>> signalling the condition, I wouldn't need the whole synchronization
>> at all.
> You want to be sure, a thread started in step 2 has finished, before you 
> proceed to step 4 ..

Ahh, yes. Now I see where you're going. What you're saying is that 
RTLEvent can't be used asynchronously (i.e. from different threads 
signalling each other) in a consistent way.

Well, *that* should be documented. I thought, trying to achieve exactly 
that behaviour was the whole idea.

> btw. this is not TEvent, we are talking about, it's rtlevent .. TEvent 
> (in synconjs) is implemented differently, and should work like delphi/
> windows TEvent, except that it is not capable of timedwait ..

Well, if I'm looking at it correctly that's only because its 
implementation is based on the POSIX semaphore. It could be using the 
phtread_mutex stuff instead. The pthread-primitives are used anyway, so 
I don't see problems with dependencies on  libpthread/libc or so...

Hmm, *looking closer* ... are there any differences between 
Darwin/BSD/Linux/Solaris code at all? AFAICS, all these implementations 
could be merged into a single one for Unix/POSIX targets.


More information about the fpc-pascal mailing list