[fpc-pascal] Semaphore problems
JeLlyFish.software at gmx.net
Tue Jul 25 10:15:29 CEST 2006
On Tuesday 25 July 2006 07:46, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> > On Tuesday 25 July 2006 06:40, Micha Nelissen wrote:
> >> Vinzent Höfler wrote:
> >>> because we assume it's non-recursive, that was the whole point.
> >>> So we should *first* check the count and then may lock/unlock the
> >>> mutex accordingly.
> >> Note that these two actions must be atomic.
> > Oh, really?
> Ehm, no.
Ehm, yes. I was being ironic here. Of course, the action of checking the
counter and locking/unlocking the associated mutex must be atomic.
> Got confused a bit :-). Reread the thread, and think your
> latest implementation as posted here is ok.
No, it's not. As usually I should sit down with pencil, paper, a cup of
coffee and a cigarette before writing code. Anything else is hacking
and takes more time and changes. (Why the hell don't I listen to
Despite the fact that some minor details may be still missing, like
setting the owner's ThreadId, for example, this implementation has one
very major flaw. It doesn't suspend the calling thread if it's not
already owned by it and if it is, it doesn't do that either, becaus it
shouldn't. That makes it kind of useless, I think. :)
Instead of exiting with (NOT_OWNED) the mutex should be locked, of
course. But before doing that, the Owner_Check_Lock must be released.
And now I start smelling a race condition. Back to the drawing board, I
More information about the fpc-pascal