751
Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Uenal Mutlu
Date : Mon May 16 2005 05:02 pm

"Torsten Robitzki" wrote
> Uenal Mutlu wrote:
>
> > "David Schwartz" wrote
> >
> >>"Uenal Mutlu" wrote
> >>
> >>    Yes, it can and must know that it already has the lock. A function that
> >>operates on X should be defined as being called with X locked, or with X
> >>unlocked. It could even take a boolean that indicates whether the caller has
> >>locked the object or not, though this is rarely the right thing to do.
> >
> > You are unnecessarily complicating things and make the program
> > slower by doing these testings.
>
> It doesn't really matter if you code this test by yourself or let the
> recursive lock do this test for you. As this explicit coded flag does
> not need any synchronization it might even be faster then the necessary
> test a recursive lock have to do.
>
>  > These tests are not necessary if
> > your design is good.
>
> Right, and the only way to get rid of this tests is to design the code
> in such a way that you know for every function if a lock is held of if a
> lock have to be acquired.

That's the point. I'm arguing that one should not think this way.
I prefer the following "contract" (I wrote about this in prev. posting):
  It is the caller's job to call f() only after having the lock.
  It is not f()'s job to check whether the object was locked or not.
If you follow this theorem then you don't need to know inside f()
whether the necessary lock was set or not. Locking should be
done by the caller, not by the called one.
The net effect of this guideline is that it simplifies many things.

> P.S. never used recursive locks and never had any serious problems with
> deadlocks.

Just curious: for which target OS do you program and which thread pkg do you use?

.

0