[thread] Assertion failed get_system_time_sentinel()
Hi, I get Assertion failed timed_lock(::boost::detail::get_system_time_sentinel()), file c:\boost\thread\win32\basic_timed_mutex.hpp, line 64. Code in basic_timed_mutex.hpp: void lock() { BOOST_VERIFY(timed_lock(::boost::detail::get_system_time_sentinel())); //Line 64 } Code in thread_time.hpp: namespace boost { ... namespace detail { inline system_time get_system_time_sentinel() { return system_time(boost::posix_time::pos_infin); } ... } } I read in a previous thread that this was a known bug that is fixed in Boost 1.38 but i am using Boost 1.38. Is this another bug or is it not fixed? This only happends sometimes and it happends when i call wait on a condition variable. Here is my code, i have marked where Assertion failed happends. boost::mutex::scoped_lock lock(_mutex); while(_queue.empty()) { _condition.wait(lock); } //Assertion failed happends here. //Another thread is signaling the condition variable when an element is added to the _queue. I am happy with all sorts of helpful comments. Best regards
Filip Klasson <filkl784@student.liu.se> writes:
Hi,
I get Assertion failed timed_lock(::boost::detail::get_system_time_sentinel()), file c:\boost\thread\win32\basic_timed_mutex.hpp, line 64.
Code in basic_timed_mutex.hpp: void lock() {
BOOST_VERIFY(timed_lock(::boost::detail::get_system_time_sentinel())); //Line 64 }
That really is bizarre. Can you show a minimal example that demonstrates the problem?
Here is my code, i have marked where Assertion failed happends.
boost::mutex::scoped_lock lock(_mutex); while(_queue.empty()) { _condition.wait(lock); } //Assertion failed happends here. //Another thread is signaling the condition variable when an element is added to the _queue.
What is the lifetime of the various elements _mutex, _condition and _queue? Is it possible that they have been destroyed by another thread? Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams 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
Here is an example that demonstrates the problem: //TestBoostTimeSentinel.cpp: #include "Test.h" void main() { for (int i=0; i<100; i++) { Test* a = new Test(); delete a; } } //Test.h: #include <boost/thread/condition_variable.hpp> #include <queue> class Test { public: Test(void); ~Test(void); private: void start(); boost::shared_ptr<boost::thread> _executorThread; mutable boost::mutex _mutex; std::priority_queue<int, std::string, std::less<int> > _prioQueue; boost::condition_variable _emptyQueueCondition; }; //Test.cpp: #include "Test.h" Test::Test(void) : _executorThread(boost::shared_ptr<boost::thread>(new boost::thread(&Test::start, this))) {} Test::~Test(void) {} void Test::start() { while (true) { boost::mutex::scoped_lock lock(_mutex); while (_prioQueue.empty()) { _emptyQueueCondition.wait(lock); } } } I use a for-loop because the problem doesnt occur every time. 2009/3/30 Anthony Williams <anthony.ajw@gmail.com>
Filip Klasson <filkl784@student.liu.se> writes:
Hi,
I get Assertion failed timed_lock(::boost::detail::get_system_time_sentinel()), file c:\boost\thread\win32\basic_timed_mutex.hpp, line 64.
Code in basic_timed_mutex.hpp: void lock() {
BOOST_VERIFY(timed_lock(::boost::detail::get_system_time_sentinel())); //Line 64 }
That really is bizarre. Can you show a minimal example that demonstrates the problem?
Here is my code, i have marked where Assertion failed happends.
boost::mutex::scoped_lock lock(_mutex); while(_queue.empty()) { _condition.wait(lock); } //Assertion failed happends here. //Another thread is signaling the condition variable when an element is added to the _queue.
What is the lifetime of the various elements _mutex, _condition and _queue? Is it possible that they have been destroyed by another thread?
Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Filip Klasson <filkl784@student.liu.se> writes:
Here is an example that demonstrates the problem:
//TestBoostTimeSentinel.cpp: #include "Test.h"
void main() { for (int i=0; i<100; i++) { Test* a = new Test(); delete a; } }
So you are creating an object and immediately destroying it.
Test::Test(void) : _executorThread(boost::shared_ptr<boost::thread>(new boost::thread(&Test::start, this))) {}
The constructor starts a new thread.
Test::~Test(void) {}
But the destructor doesn't wait for it to finish.
void Test::start() { while (true) { boost::mutex::scoped_lock lock(_mutex); while (_prioQueue.empty()) { _emptyQueueCondition.wait(lock); } } }
and the thread body accesses local variables. This is undefined behaviour --- your threads are outliving the variables they are accessing. You need to join with the thread before you destroy the object. Since you start the thread in the constructor, it would make sense to call join in the destructor. Test::~Test(void) { _executorThread->join(); } Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams 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
Ok, thanks for the information. Just one question, Is it still a problem if i access local variables if i join the thread in the destructor? 2009/3/30 Anthony Williams <anthony.ajw@gmail.com>
Filip Klasson <filkl784@student.liu.se> writes:
Here is an example that demonstrates the problem:
//TestBoostTimeSentinel.cpp: #include "Test.h"
void main() { for (int i=0; i<100; i++) { Test* a = new Test(); delete a; } }
So you are creating an object and immediately destroying it.
Test::Test(void) : _executorThread(boost::shared_ptr<boost::thread>(new boost::thread(&Test::start, this))) {}
The constructor starts a new thread.
Test::~Test(void) {}
But the destructor doesn't wait for it to finish.
void Test::start() { while (true) { boost::mutex::scoped_lock lock(_mutex); while (_prioQueue.empty()) { _emptyQueueCondition.wait(lock); } } }
and the thread body accesses local variables.
This is undefined behaviour --- your threads are outliving the variables they are accessing. You need to join with the thread before you destroy the object. Since you start the thread in the constructor, it would make sense to call join in the destructor.
Test::~Test(void) { _executorThread->join(); }
Anthony -- Author of C++ Concurrency in Action | http://www.manning.com/williams 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
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
----- Original Message ----- From: "Filip Klasson" <filkl784@student.liu.se> To: <boost@lists.boost.org> Sent: Tuesday, March 31, 2009 8:15 AM Subject: Re: [boost] [thread] Assertion failed get_system_time_sentinel()
Ok, thanks for the information. Just one question, Is it still a problem if i access local variables if i join the thread in the destructor?
Hi, No this is one of the possibilities. You can take a look on N2802: A plea to reconsider detach-on-destruction for thread objects (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2802.html) which explains clearly the issue. Best, Vicente
AMDG Filip Klasson wrote:
Here is an example that demonstrates the problem:
//TestBoostTimeSentinel.cpp: #include "Test.h"
void main() { for (int i=0; i<100; i++) { Test* a = new Test(); delete a;
The other thread is still using a.
<snip>
2009/3/30 Anthony Williams <anthony.ajw@gmail.com>
What is the lifetime of the various elements _mutex, _condition and _queue? Is it possible that they have been destroyed by another thread?
Sure enough. In Christ, Steven Watanabe
participants (4)
-
Anthony Williams -
Filip Klasson -
Steven Watanabe -
Vicente Botet