Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler: > On Monday 24 July 2006 14:57, Burkhard Carstens wrote: > > I vote for more pascal based versions of TMutex, TSemaphore and > > TEvent, that behaves just like the ones in Delphi and use the > > system specific functions (like pthread stuff) only internally in > > their simplest/most portable form. > > I'd vote for a more abstract version. :) The more or less basic > things needed in multi-threaded programing are > > - semaphore > - persistent signal > - transient signal ("pulse") > - event > > There's some more higher level stuff (like broadcasts, for example), > but that's about all you usually need. Currently we have the > semaphore (more or less as SyncObjs.tCriticalSection), the persistent > and the transient signal (SyncObjs.tEvent), although without timeouts > (at least when trying to be portable), the event is somewhat > implemented, but IIRC it misses a "Toggle" property, which can be > used for simple intertask communication ("Now I'm blocking, you're > on."). > > > Currently, I have the problem to get a working TEvent: > > - The one in syncobjs returns wrError, when it's waitfor is called > > with anything else tah infinite timeout > > Yes, that's not implemented, although it should be easily added by > using condition variables of pthreads.
..which currently doesn't work, unless someone applies my patch (or a better one) .. > > > - the rtlEvent works even with timeout (with my patch posted on > > mantis), but this one clears the signaled state, when wait is > > called. > > *oh* Before the wait? That's not good. This cries for race conditions > and subtle deadlock situations. thread synchronization uses this and takes care of it by calling RTLeventstartwait which locks the associated mutex. So I don't expect a race condition there, but don't know about other places. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal