Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Uenal Mutlu
Date : Wed May 18 2005 10:47 pm

"David Schwartz" wrote
>
> "Uenal Mutlu" wrote in message
> > "David Schwartz" wrote
> >>
> >> "Uenal Mutlu" wrote in message
> >>
> >> > You seem to not understand what I'm talking about.
> >> > Do you understand this fact: "Recursive locking is defined for the
> >> > current
> >> > lock owning
> >> > thread only"?
> >> > Since you already have the lock you can do what ever you want since
> >> > nobody
> >> > else can change anything, but you can do! You simply increment it in
> >> > Lock()
> >> > and decrement it in Unlock(). Because it is safe because you already
> >> > have
> >> > it locked.
> >>
> >>     Holy cow! Have you actually seen the way any recursive lock is
> >> actually
> >> implemented?
> >
> > Sure, I've even researched and stress tested them, developed many variants
> > myself.
> > Otherwise I wouldn't discuss them. For code see my reply to doug.
>
>     If you mean this:
>
>  void Lock(someparam)
>  {
>    if (TryLock(someparam))
>      return;
>    //...magic and undisclosed part here :-)
>  }
>
>  void Unlock(someparam)
>  {
>    //...magic and undisclosed part here :-)
>  }
>
>  bool TryLock(someparam)
>  {
>    if (++cLocked == 1)  // actually an atomic pre-increment operator (ie.
> class method)
>    {
>      // first Lock; ie. thread has locked it
>      //...magic and undisclosed part here :-)
>    }
>    // else test whether the current thread is the same thread which holds
> the lock,
>    // and if yes then return success (counter cLocked will be >1)
>
>    //...magic and undisclosed part here :-)
>  }
>
>     It's so horribly broken that, if anything, it proves my point. For
> example, the 'TryLock' function increments the lock count even if some other
> thread holds the lock. It's hard to imagine how you can write a sane
> 'Unlock' function once you've made it impossible to tell whether the lock
> actually gets unlocked or not.

It is not broken, and your observation is correct. Just think of a decrement somewhere
and you'll have found the holy grail...  :-)

.