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