Re: [boost] This deadlocks on Linux but not on Windows <----- why this is important

From: Ulrich Eckhardt (doomster_at_[hidden])
Date: 2008-02-08 11:45:36

On Thursday 07 February 2008 05:39, Clark Sims wrote:
> I defined this class for managing a thread group, with different priorities
> for different threads    http://rafb.net/p/u0LDDP45.html       I wrote this
> test example:   http://rafb.net/p/bAIhrh79.html 

FYI, both URLs don't work, pastebins are short-timed...

> it works perfectly in linux,  generating this output : 
> http://acumenconsultinginc.net/linux.results.txt   on windows,  it calls
> the appropriate locks, but it does not stop when two locks, lock the same
> mutex:  http://acumenconsultinginc.net/windows.results.txt.

It already causes 'undefined behaviour' on Linux. A mutex that is guaranteed 
to be non-recursive is useless. The reason is that if you lock a mutex and 
then try to lock it again and block, you will never continue from there on 
because you are waiting for a mutex you hold yourself. If you think that a 
different thread could release the lock for you, you are mistaken, you can 
only release a lock from the thread it was acquired from.

> My class for managing threads, based upon priorities, won't work unless the
> previous small code fragment deadlocks.

You never want deadlocks, because they are final by definition. I guess (I 
don't know, since the code is not available...) that you want something 
different, but it's really hard to tell.

Uli