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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
