[fpc-pascal] Semaphore problems

Burkhard Carstens fpc at bcsoft.de
Mon Jul 24 17:41:16 CEST 2006


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.




More information about the fpc-pascal mailing list