Subj : Re: recursive mutexes
To   : comp.programming.threads
From : Uenal Mutlu
Date : Mon May 16 2005 12:29 pm

"Sergei Organov" wrote
> "Uenal Mutlu"
> > "David Schwartz" wrote
> > > I never argued the performance issue. But here's a more realistic example:
> >
> > The example was in response to Peter's posting who wrote "No, he's in fact
> > making the program faster."
> >
> > To your question regarding the speed of recursive vs. non-recursive
> > locks: True, recursive locking is slower than non-recursive locking.
> > But recursive locking simplifies coding (no need to have a locked and
> > unlocked version of a function) and makes the application safer wrt
> > self-deadlocking.
>
> Yes, it simplifies coding in the sense that it makes it easier to write
> "working" program that is in fact incorrect. Please try to understand
> what others already told you: dead lock could be a good thing as getting
> it early and correct the problem is much better than hiding the problem
> behind recursive locks.

But you forget the fact that recursive locks have the property to
not deadlock the thread. Then it is not valid to say that because
I called Lock() twice that this leads to deadlock, no!  I'm willingly
making use of its recursivity feature because it simplifies many things,
and most importantly it is safer than non-recursive locking, though
it has a neglectable overhead. If I use a _recursive locking method_
then I'm of course aware of these facts.

> If you in fact don't care about correctness of your programs, it's

I do care very much of the correctness of my program. It has highest
priority, second is performance, third is simplicity/maintainability.

> better to get rid of all the locking altogether, -- absolutely safe wrt
> deadlocks, simple, and pretty fast program you will get ;)

 :-)
Unfortunately, impossible to not use locking in nowadays projects.
Locking has become very important and will be in future.
Lockless shared access is practically seen impossible to do if
there are at least two threads sharing the same resource.

.