64f
Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Uenal Mutlu
Date : Mon May 16 2005 07:30 am

"doug" wrote
>
> "Uenal Mutlu" wrote
> > "Peter Dimov" wrote
> >> Uenal Mutlu wrote:
> >> > "Peter Dimov" wrote
> >> >> Uenal Mutlu wrote:
> >> >>> "David Schwartz" 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.
>
> > You don't need 2 versions of g() if you use recursive locking.
> > The overhead of recursive locking is neglectable because
> > it's just incrementing a counter in Lock() and decrementing it in
> > Unlock().
>
> S'not true.  You can't just increment/decrement a counter in
> Lock()/Unlock() - these operations require memory barriers or they won't
> work properly across multiple threads and CPUs.  With recursive locks, too.

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.

.

0