[fpc-pascal] Semaphore problems
fpc at bcsoft.de
Mon Jul 24 19:51:46 CEST 2006
Am Montag, 24. Juli 2006 19:22 schrieb Vinzent Höfler:
> Burkhard Carstens wrote:
> > Am Montag, 24. Juli 2006 17:27 schrieb Vinzent Hoefler:
> >>> - 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.
> As far as I just read code and comments, it does it for Windows to
> get Unix behaviour, although I don't see the point here, because this
> just forces the race condition the POSIX-Threads implementation
> actually tries to circumvent with this associated mutex.
I don't think so. In unix, the mutex is locked, which ensures, there is
not setevent between startwait and actual call to wait, because the
call to wait seems to reset the cond, then releases the mutex and
starts waiting. In windows, this doesn't matter (resetting the event on
startwait), because it preserves the signaled state of the event. The
wait call just returns immediately, if the event is allready signaled.
To me, this is fine. As long as rtlevent is used with this in mind, it
should give a consistent behaviour on windows and linux. (see
classes.inc thread synchronization)
> I'm not even sure, if Unix actually clears the event. The man-pages
> don't seem to indicate so.
It does, at least with the timedwait. I tested that extensively.
More information about the fpc-pascal