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

Reply via email to