cf6
Subj : Re: recursive mutexes
To   : comp.programming.threads
From : doug
Date : Mon May 16 2005 10:07 pm


"doug" <noone@nowhere.co.uk> wrote in message 
news:xv2ie.56043$a9.49780@fe3.news.blueyonder.co.uk...
>
> "Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
> news:d6aae5$9ac$02$1@news.t-online.com...
>> "Torsten Robitzki" wrote
>>> Uenal Mutlu wrote:
>>>
>>> > "doug" wrote
>>> >
>>> >>>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.
>>> >>>
>>> >>
>>> >>Think carefully.  How is this possible?
>>> >
>>> > 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.
>> Do you know what a critical section is?
>
> He's getting at this - how do you decide if you own the lock?  If multiple 
> threads can possibly be reading/writing the same location, you need 
> synchronisation.  If not, why are you even using a lock in the first 
> place?
>
> You say "The code which increments the counter cannot be executed by 
> anyone else but the current lock holding thread."  But how does the 
> current thread know if has the lock?  I assume this is code internal to 
> the Lock() routine, but surely it must be accessing some shared data - a 
> field in the lock saying who owns it, for example?
>
> See my post above.  Write some pseudocode for Lock() and we'll see.
>
>
>>
>> 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?
>> For which OS and using which threading pkg do you develop?
>>
>>
>>
>
>
Another thought occurred to me while in the pub.  Your specialisation of the 
hierarchical locking theorem has another serious drawback.  Not only does 
each thread have to know exactly what it has done in the past (i.e. you must 
have predefined sets of callstacks, limiting flexibility), but each thread 
*needs to know exactly what every other thread is doing too*.  This is a 
huge drawback - bang goes your decoupled design.  Components will be so 
coupled in their locking requirements, that any serious long-term 
maintenance and/or large scale project will be doomed to failure.  You are 
writing code to work with other threads, rather than a set of well-defined 
rules.

.

0