Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : Uenal Mutlu
Date : Wed May 04 2005 08:33 am

The new rule d should clarify most of the issues (cf. other posting).


"David Schwartz" wrote
> "Uenal Mutlu" wrote
>
> > while (!IsEnd())
> > {
> >    Locker L(o1.LV);
> >    o1.DoStuff();
> > }
>
>     The problem is, if the object is already locked, the construction and
> destruction of the locker does nothing. This is a great example of the
> pitfalls of recursive locks.

If the lock owner is a different thread then the requesting thread must wait.
If it is himself who already owns the lock then recursive locking will be done.

> > By this, the object is locked only for the duration of one iteration
> > of the loop. It is locked and unlocked permanently to make real
> > shared (parallel) processing possible; ie. multiple threads can work
> > on the same data (for example a vector) at the same time.
>
>     If the lock is recursive, how do you know it's not still locked? If your
> answer is that the programmer must make sure the object is not locked before
> entering the loop, then how does recursive locks help him?

Usually one doesn't need to know whether a lock is active. You just try
to get the lock and when it succeeds then it is you who owns the lock,
nobody else can own it at the same time. But it is of course possible
(just an implementation case) to query whether an object is locked,
and by which thread etc. (see new rule d)

> > Locker L(o1.LV);
> > while (!IsEnd())
> > {
> >    o1.DoStuff();
> > }
> >
> > Here the thread does one Lock() and keeps the object locked for
> > a long period, all other threads needing access to this object must
> > wait until this thread releases the lock. This method is IMO slower
> > (in terms of application performance) than the above (regarded multiple
> > threads need to access the object), although the other method does
> > myriads of locking and unlocking whereas this one makes just one lock.
>
>     This won't work. If 'IsEnd' acquires and releases a lock, then your
> rules are violated since 'IsEnd' is in the same block as 'DoStuff'. If
> 'IsEnd' does not acquire any locks, then it can never return a different
> value because no lock is released to allow another thread to change the
> return value.

Ok, the new rule d should have covered this now.

.