[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.
Vinzent.
More information about the fpc-pascal
mailing list