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