Am Montag, 24. Juli 2006 22:05 schrieb Vinzent Höfler: > 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...
My idea was to use a rtlevent additionally and only when waitfor is called with timeout AND event is not signalled yet. > 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. Don't know, maybe. However, we use PTHREAD_MUTEX_RECURSIVE_NP, where NP stands for NotPortable.. don't know which platforms support it and which not. That's why I voted for implementing most of the functionality in pascal and use pthread primitives only in their basic (i.e. mutex in non-recursive) form.. Burkhard _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal