Geoff Shapiro wrote:

Anthony Williams writes:

...

interrupt_all is not blocking. However, there is currently a bug in interruption on pthreads which means threads can miss interruptions if they get a spurious condition variable wake at the wrong time. Since interruption causes spurious wakes for other threads waiting on the same cv this is particularly a problem for interrupt_all.

Anthony, what is the schedule, if any, for getting a fix for the bug you refer to? The project I am currently working on, in development within a win32 environment, but soon to be ported to a VxWorks/PPC (using pthreads) environment does use interruption facilities. If this will be a problem for us, let's say not fixed up within the next 6 months, then I'll have to utilize alternate schemes.

Geoff Shapiro FLIR Systems, Inc.

There was a discussion about this topic a few weeks ago, e.g.: http://lists.boost.org/boost-users/2009/12/54165.php If I got it right, a workaround is { boost::mutex::scoped_lock lock(mutex_); // lock the mutex of the cv threadGroup_.interrupt_all(); } // unlock the mutex HTH, Roland

Geoff Shapiro writes:

Anthony Williams writes:

...

interrupt_all is not blocking. However, there is currently a bug in interruption on pthreads which means threads can miss interruptions if they get a spurious condition variable wake at the wrong time. Since interruption causes spurious wakes for other threads waiting on the same cv this is particularly a problem for interrupt_all.

Anthony, what is the schedule, if any, for getting a fix for the bug you refer to? The project I am currently working on, in development within a win32 environment, but soon to be ported to a VxWorks/PPC (using pthreads) environment does use interruption facilities. If this will be a problem for us, let's say not fixed up within the next 6 months, then I'll have to utilize alternate schemes.

I have an idea on how to fix it; I just need to find the time to try it out. Anthony -- Author of C++ Concurrency in Action http://www.stdthread.co.uk/book/ just::thread C++0x thread library http://www.stdthread.co.uk Just Software Solutions Ltd http://www.justsoftwaresolutions.co.uk 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK. Company No. 5478976

On Tue, Jan 26, 2010 at 4:22 PM, Anthony Williams wrote:

Sachin Garg writes:

...

Does a call to interrupt_all blocks the calling thread, waiting for all threads to be interrupted? Or is it supposed to return immediately and let the threads hit their interruption points later?

interrupt_all is not blocking.

My blocking problem seems to be because I am calling interrupt_all when another thread is already waiting on a join_all for same thread_group. Similar to the issue described in the post below. I am using boost 1.39.0, is this fixed in current 1.41.0? http://lists.boost.org/boost-users/2009/10/53107.php

However, there is currently a bug in interruption on pthreads which means threads can miss interruptions if they get a spurious condition variable wake at the wrong time. Since interruption causes spurious wakes for other threads waiting on the same cv this is particularly a problem for interrupt_all.

I think I can live with this bug for a while :-) let me know if I am misunderstanding it. The condition variable bug *seems* to mean that in worst case a thread a may miss one interruption point and then get interrupted at its next interruption point (the interruption is not lost, just delayed) This will be ok in my application as missing an interruption is not fatal and it does not cause any deadlocks etc (the thread will surely reach its next interruption point soon and then get interrupted). Is the fix for this expected in 1.42.0? 1.42.0 release seems to be very close. Anyway, if my understanding of bug is correct, I can live with it for a while. Thanks for your help. SG