This deadlocks on Linux but not on Windows <----- why this is important
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 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. My class for managing threads, based upon priorities, won't work unless the previous small code fragment deadlocks. --------------------------------- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
Clark Sims <clark_sims_boost <at> yahoo.com> writes:
I defined this class for managing a thread group, with different priorities
http://rafb.net/p/u0LDDP45.html I wrote this test example: http://rafb.net/p/bAIhrh79.html 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.
My class for managing threads, based upon priorities, won't work unless the
for different threads previous small code fragment deadlocks. Those URLs don't work for me, but presumably what you want is something that blocks until something is queued to be run by one of the threads in the group. My suggestion would be to use semaphores rather than mutexes for this. You initialize the semaphore count to 0 so that the first time you wait for it you immediately block. When another thread signals the semaphore you wake up. You'll have to write your own cross-platform semaphore class though as Boost.Thread doesn't have one. Colin
The boost::interprocess library has a semaphore that should work even though its probably overkill. -ges
-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Colin Caughie Sent: Friday, February 08, 2008 3:00 AM To: boost@lists.boost.org Subject: Re: [boost] This deadlocks on Linux but not on Windows <----- why this is important
Clark Sims <clark_sims_boost <at> yahoo.com> writes:
I defined this class for managing a thread group, with different
http://rafb.net/p/u0LDDP45.html I wrote this test example: http://rafb.net/p/bAIhrh79.html it works perfectly in linux, generating this output : http://acumenconsultinginc.net/linux.results.txt on windows, it calls
it does not stop when two locks, lock the same mutex: http://acumenconsultinginc.net/windows.results.txt.
My class for managing threads, based upon priorities, won't work unless
priorities for different threads the appropriate locks, but the previous small code fragment deadlocks.
Those URLs don't work for me, but presumably what you want is something that blocks until something is queued to be run by one of the threads in the group. My suggestion would be to use semaphores rather than mutexes for this. You initialize the semaphore count to 0 so that the first time you wait for it you immediately block. When another thread signals the semaphore you wake up.
You'll have to write your own cross-platform semaphore class though as Boost.Thread doesn't have one.
Colin
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Friday 08 February 2008 02:59, Colin Caughie wrote:
Those URLs don't work for me, but presumably what you want is something that blocks until something is queued to be run by one of the threads in the group. My suggestion would be to use semaphores rather than mutexes for this. You initialize the semaphore count to 0 so that the first time you wait for it you immediately block. When another thread signals the semaphore you wake up.
You'll have to write your own cross-platform semaphore class though as Boost.Thread doesn't have one.
Why would you do that? Boost.thread does provide boost::condition, which isn't exactly a semaphore but conditions are designed for just the purpose you describe. -- Frank
Frank Mori Hess <fmhess <at> speakeasy.net> writes:
Why would you do that? Boost.thread does provide boost::condition, which isn't exactly a semaphore but conditions are designed for just the purpose you describe.
So it does! I hadn't noticed that before. Presumably this works just like Posix condition variables? OK forget what I said about semaphores, boost::condition should do exactly what you need. :) Unless you need counting of course, but you probably don't. Colin
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
participants (5)
-
Clark Sims -
Colin Caughie -
Frank Mori Hess -
Schrader, Glenn -
Ulrich Eckhardt