Subj : Re: Deadlock theorem
To   : comp.programming.threads
From : David Schwartz
Date : Tue May 03 2005 08:46 pm


"Uenal Mutlu" <520001085531-0001@t-online.de> wrote in message 
news:d590ka$cmo$01$1@news.t-online.com...

> 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.

> 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?

> 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.

    DS

.