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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk