[Thread] barrier destruction after wait() results in assertion
Boost 1.37.0, Red Hat Enterprise Linux 5 x86_64, gcc 4.1:
The following simple test establishes a barrier with thread count 2.
One of the threads destroys the barrier after returning from wait(). This results in sporadic assertions from ~mutex().
boost/thread/pthread/mutex.hpp:45: boost::mutex::~mutex(): Assertion `!pthread_mutex_destroy(&m)' failed.
#1 0x00000038306295d6 in __assert_fail () from /lib64/libc.so.6
#2 0x000000000040245a in ~mutex (this=0x1f63f010) at boost/thread/pthread/mutex.hpp:45
#3 0x0000000000402488 in ~barrier (this=0x1f63f010) at boost/thread/barrier.hpp:24
I assume that this usage of barrier is not supported/allowed. One cannot assume that the barrier can be destroyed just because the corresponding thread returned from wait().
Is this conclusion correct?
Regards, Peter.
#include
Peter Klotz
Boost 1.37.0, Red Hat Enterprise Linux 5 x86_64, gcc 4.1:
The following simple test establishes a barrier with thread count 2.
One of the threads destroys the barrier after returning from wait(). This results in sporadic assertions from ~mutex().
I assume that this usage of barrier is not supported/allowed. One cannot assume that the barrier can be destroyed just because the corresponding thread returned from wait().
Is this conclusion correct?
You cannot destroy a barrier whilst a thread may be accessing it.
#include
#include #include boost::scoped_ptrboost::barrier barrier;
void f() { barrier->wait(); }
int main(void) { barrier.reset(new boost::barrier(2)); boost::thread thread(boost::bind(&f)); barrier->wait();
At this point, there is no guarantee that f() has started.
barrier.reset();
So this call may have just destroyed the barrier that f is about to wait on.
thread.join(); return 0; }
Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
Anthony Williams: ...
void f() { barrier->wait(); }
int main(void) { barrier.reset(new boost::barrier(2)); boost::thread thread(boost::bind(&f)); barrier->wait();
At this point, there is no guarantee that f() has started.
Yes there is.
"Peter Dimov"
Anthony Williams: ...
void f() { barrier->wait(); }
int main(void) { barrier.reset(new boost::barrier(2)); boost::thread thread(boost::bind(&f)); barrier->wait();
At this point, there is no guarantee that f() has started.
Yes there is.
Doh! Thanks Peter, apparently I'm not thinking straight today. Anyway, there is no guarantee that the call to wait in f() has *completed*, which means it might still own the mutex in barrier, which means it is not safe to destroy the barrier at this point. Anthony -- Anthony Williams Author of C++ Concurrency in Action | http://www.manning.com/williams Custom Software Development | http://www.justsoftwaresolutions.co.uk Just Software Solutions Ltd, Registered in England, Company Number 5478976. Registered Office: 15 Carrallack Mews, St Just, Cornwall, TR19 7UL, UK
Anthony Williams: ...
void f() { barrier->wait(); }
int main(void) { barrier.reset(new boost::barrier(2)); boost::thread thread(boost::bind(&f)); barrier->wait();
At this point, there is no guarantee that f() has started.
Yes there is.
Doh! Thanks Peter, apparently I'm not thinking straight today.
Anyway, there is no guarantee that the call to wait in f() has *completed*, which means it might still own the mutex in barrier, which means it is not safe to destroy the barrier at this point.
Thanks for this clarification. Regards, Peter.
participants (3)
-
Anthony Williams -
Peter Dimov -
Peter Klotz