707
Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Torsten Robitzki
Date : Mon May 16 2005 05:45 pm

Uenal Mutlu wrote:

> "Torsten Robitzki" wrote
> 
>>Uenal Mutlu wrote:
>>>
>>>It is really basic stuff. Ask yourself how you would extend a non-recursive
>>>locking method to make it recursive? Recursivity starts with the 2nd Lock()
>>>call on the same object within the same thread, true?
>>
>>First one have to check if this lock request comes from the thread
>>holding the mutex or not. This can not be implemented by a simple
>>increment.
> 
> 
> I can only repeat: The code which increments the counter cannot be
> executed by anyone else but the current lock holding thread.

What will a thread that does not hold the lock prevent it from 
incrementing the counter if not by checking if it's holding the lock or 
not? A lock is not some magical device, it's just a bunch of data with 
some associated functions. Looks to me that you are inventing a thread 
private lock here ;-)

> Do you know what a critical section is?

Sure, it Microsoft's name for a recursive, maybe a little bit spinning 
in front of blocking, mutex or lock.

> In your other posting you wrote:
> 
> 
>>P.S. never used recursive locks and never had any serious problems with
>>deadlocks.
> 
> 
> May I ask: have you ever either implemented any mutex (recursive or non-recursive)
> by yourself or have you ever used a non-recursive mutex in your projects?

I've implemented a mutex (both recursive and non-recursive) in a very 
simple manner by using an atomic swap plus wait. And yes I'm using 
non-recursive locks in my projects.

> For which OS and using which threading pkg do you develop?

OpenVMS/Alpha with some C++ wrapper around pthread.

.

0