Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : Uenal Mutlu
Date : Wed May 04 2005 06:37 pm

"David Schwartz" wrote
>
> "Uenal Mutlu" wrote
>
> >> > Locker L(o1.LV);
> >> > while (!IsEnd())
> >> > {
> >> >    o1.DoStuff();
> >> > }
>
> >>     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.
>
>     Nope, this code is still illegal by your current rules. There are two
> possibilities:
>
>     1) IsEnd acquires and releases a lock. In this case, your rule 'd' is
> violated.

Hmm. rule d is there to permit exactly this situation. How can it violate it?

>     2) IsEnd acquires no locks. In this case, the code is unsafe and can
> never ensure 'IsEnd' returns the right value.

Why is it unsafe?
All parts of a program have to be correct, obviosly.
It's correct only when within the function all concurrently used
shared objects are locked (following the rules).
On the other hand, if the function does not make use of any
concurrently used shared object then it is of course safe too;
it does not need to lock anything.

>     In most cases, 'IsEnd' will have to acquire a lock of some kind. This
> violates rule 'd' of your hierarchy.

I can only repeat:  rule d is there to permit exactly this situation. How can it violate it?

.