Subj : Re: recursive mutexes
To   : comp.programming.threads,comp.unix.programmer
From : Uenal Mutlu
Date : Sun May 15 2005 05:45 pm

"Måns Rullgård" wrote
> "Uenal Mutlu" writes:
>
> >> >>     The problem is that recursive mutexes hide something from
> >> >> you and that something is extremely important. Consider code
> >> >> like this:
> >> >>
> >> >> A) Lock mutex
> >> >> B) Unlock mutex
> >> >> C) Do something, assuming the mutex is unlocked
> >> >>
> >> >>     What happens if the mutex is recursive?
> >> >
> >> > Recursive locks work only for the same (current) thread.
> >>
> >> I sure hope so.
> >>
> >> > The code above is IMO wrong, obviously it should be:
> >> >  A) Lock mutex
> >> >  B) Do something
> >> >  C) Unlock mutex
> >>
> >> David meant what he said.  What if the something is signaling another
> >> thread to go ahead with something that locks the mutex, and then wait
> >> for that other thread to signal you back?  Deadlock.
> >
> > This has nothing to do with recursive locking per se, does it? I
> > mean: the same would happen also without recursive locking, wouldn't
> > it?
>
> No, because having unlocked the mutex, you can be certain that the
> other thread will be able to acquire it.  If the mutex is recursive,
> you can't know which level you just unlocked.

You are expecting a specific thread will get the released lock?
This can't work.

> > And, apart from that I don't think this way. In my thinking each
> > thread knows itself only and tries to lock the shared object(s)
> > before changing its/their content. We are talking of locking some
> > shared objects here, don't we?
>
> If "each thread knows itself only", how can we be talking about shared
> objects at all?

Because we are talking of threads and not processes...

> > You maybe should give a practical example in pseudocode for what you
> > mean.
>
> I don't think that's needed.

It sure would clarify what you mean.

> >> > and this is ok too (here the recursive feature is in action):
> >> >  A) Lock mutex
> >> >  B) Do something
> >> >  C) Lock mutex
> >> >  D) Do something2
> >> >  E) Unlock mutex
> >> >  F) Unlock mutex
> >> >
> >> > C and E are redundant, however application code (the current thread)
> >> > cannot always know that it alread has the lock, though it could test
> >> > for it.
> >>
> >> Bad application design.  A properly designed application will always
> >> know what to expect.
> >
> > This is a shortsighted view. What do you think recursive locking is
> > intended for?
>
> They are for lazy programmers unwilling to learn proper design.

I would say this applies exactly to yourself.

> > Recursive locking has nearly no overhead if the implementation of lock()
> > and unlock() were properly done.
>
> I'm not worried about overhead.  I'm worried about writing buggy code.

Then continue worrying. Using recursive locking is safer than using
one which doesn't have such recursive feature.

> > They have many many advantages.
>
> Prove it.  Show me one problem that can't be solved better without them.

Since you don't believe me it's your turn to prove that recursive locking
is more dangerous (your saying) than using no recursive locking.
My point is: recursive locking is much safer than non-recursive locking.

> >> >>     It's just too hard and dangerous to write sensible code that
> >> >> works with a mutex that might or might not start out with that
> >> >> mutex locked and with no way to tell which. And the only value of
> >> >> recursive mutexes is that they let you do this.
> >> >
> >> > Lock objects are initialized at creation, they don't have a random
> >> > state.  Recursive locks are very practical. It saves coding and
> >> > prevents from self-deadlocking.
> >>
> >> In all the years I've been programming, I have never used a recursive
> >> mutex (except in Java, but that's another story).
> >
> > Then you must have overlooked their real value.
>
> Or I realized their real danger.

I doubt it because there is no danger in using recursive locking over
non-recursive locking. OTOH recursive locking has advantages over
non-recursive locking. So what? If you doubt this then prove it.

(Follow-up set to  comp.programming.threads where it belongs to)

.