[fpc-pascal] Semaphore problems

Burkhard Carstens fpc at bcsoft.de
Mon Jul 24 22:22:28 CEST 2006


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




More information about the fpc-pascal mailing list