Subj : Re: recursive mutexes
To   : comp.programming.threads
From : David Schwartz
Date : Wed May 18 2005 01:34 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d6g3uh$2vf$05$1@news.t-online.com...
> "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.

    DS

.