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 myself?) 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 guess. Vinzent. _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
