Our application is quite large and it's hard to determine what exactly is triggering the error. But the exception itself happens in the wait method in condition_variable_any. Actually, I do seem some calls to timed_wait so I think I might be running into similar errors. Could you point me to how others have resolved the problem? The error message that's displayed is: terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<boost::lock_error>

' what(): boost::lock_error And I've confirmed that the error only exists when using Boost 1.45, not Boost 1.38.

Here is what the wait method looks like in Boost 1.45: template<typename lock_type> void wait(lock_type& m) { int res=0; { thread_cv_detail::lock_on_exit<lock_type> guard; detail::interruption_checker check_for_interruption(&internal_mutex,&cond); guard.activate(m); res=pthread_cond_wait(&cond,&internal_mutex); this_thread::interruption_point(); //error occurs here, when lock_on_exit's destructor is called } if(res) { boost::throw_exception(condition_error()); } } This is the same method in Boost 1.38: template<typename lock_type> void wait(lock_type& m) { int res=0; { detail::interruption_checker check_for_interruption(&cond); { boost::pthread::pthread_mutex_scoped_lock internal_lock(&internal_mutex); m.unlock(); res=pthread_cond_wait(&cond,&internal_mutex); //no equivalent lock_on_exit. } m.lock(); } if(res) { throw condition_error(); } } Thanks, Ven On 02/01/2011 03:30 AM, Anthony Williams wrote:

Ven Tadipatri<ven.tadipatri@ll.mit.edu> writes:

...

Hi, We upgraded our project from using Boost 1.38 to Boost 1.45 but now seem to be having some thread issues. The error doesn't happen for every run, but occasionally the wait method in condition_variable_any fails. At other times the program seems to run into an infinite loop, presumably waiting for a lock that's never released. I looked at the changes in http://www.boost.org/doc/libs/1_45_0/doc/html/thread/changes.html but don't see what could be causing the error to occur only after upgrading to Boost 1.45. Has anyone else experienced their code breaking when upgrading to the latest version of Boost? This seems similar to the problems people have experience with boost::this_thread::sleep (which I cannot reproduce), which relies on condition_variable::timed_wait.

I don't think anything significant has changed in that area, so it surprises me that you are experiencing problems only after upgrading.

Can you give more information about the problem? A small sample application that demonstrates it would be nice.

Anthony

I'm using CentOs 5.4 and gcc 4.1.2. Any idea what changes to Boost were done that could affect it? I did have to make code changes to get it to compile, but they were related to virtualization. Would code like this have any impact on the way boost's thread locking mechanism works? //this had to be added for various header files otherwise "no unique final overrider" errors would be thrown //but it wasn't needed for Boost 1.38 namespace boost{ template<> struct is_virtual_base_of<ns::BaseClass, ns::Subclass>: public mpl::true_ {}; } We have code which checks to see if a thread is joinable. If so, it's interrupted. I suspect that behavior may have changed with the later versions of Boost. Thanks, Ven On 02/01/2011 05:35 PM, Jim Bell wrote:

On 1:59 PM, Anthony Williams wrote:

...

Ven Tadipatri<ven.tadipatri@ll.mit.edu> writes:

...

Hi, We upgraded our project from using Boost 1.38 to Boost 1.45 but now seem to be having some thread issues. [...] Has anyone else experienced their code breaking when upgrading to the latest version of Boost? This seems similar to the problems people have experience with boost::this_thread::sleep (which I cannot reproduce), which relies on condition_variable::timed_wait. Ven: What platform (operating system and compiler) are you using?

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

On 2/2/2011 2:33 AM, Viatcheslav.Sysoltsev@h-d-gmbh.de wrote:

boost::thread is quite simple component, just start your code in debugger and see where it fails. What's the point to guess if you don't provide details

Yeah, nothing like adding in a debugger to change the race conditions and hide your bugs. If there's one word I would *not* use in reference to anything multi-threaded, it's "simple".

It appears the problem has to do with the thread being interrupted. For some reason in Boost 1.45, when a thread is given the interrupt command, it's either ignored, or something is prevented from checking for the interrupt. The only change I can see in the interrupt method is the acquisition of an internal lock (line 414 in thread.cpp in Boost 1.45): boost::pthread::pthread_mutex_scoped_lock internal_lock(local_thread_info->cond_mutex); This line isn't present in Boost 1.38. As a sort of hack I was able to call interrupt on the thread, then call sleep on that thread for 20 milliseconds (some arbitrary time). The documentation states there are interruption points, so the thread only interrupts when it reaches one of those points: http://www.boost.org/doc/libs/1_45_0/doc/html/thread/thread_management.html#... Was this behavior changed so that now when interrupt is called on a thread it doesn't actually get interrupted until one of these other methods are called? Previously, when interrupt was called on a thread it would get interrupted immediately, so what's going on? Thanks, Ven On 02/02/2011 08:12 AM, Eric J. Holtman wrote:

On 2/2/2011 2:33 AM, Viatcheslav.Sysoltsev@h-d-gmbh.de wrote:

...

boost::thread is quite simple component, just start your code in debugger and see where it fails. What's the point to guess if you don't provide details

Yeah, nothing like adding in a debugger to change the race conditions and hide your bugs.

If there's one word I would *not* use in reference to anything multi-threaded, it's "simple". _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

Umm, not sure if I got you correctly: you mean one of your thread waits in condition_variable_any::timed_wait() and second tries to interrupt it, which just does not seem to make any effect? Can you write a small test case demonstrating your problem?

The following works as expected with boost 1.45: #include <string> #include <boost/thread/thread.hpp> boost::condition_variable cond; boost::mutex mut; void wait_for_data_to_process() { boost::unique_lock<boost::mutex> lock(mut); boost::xtime curTime; boost::xtime_get(&curTime, boost::TIME_UTC); curTime.sec += 10; cond.timed_wait(lock, curTime); printf("Data processed\n"); } int main() { boost::thread t(&wait_for_data_to_process); usleep(1000000); t.interrupt(); t.join(); return 0; } So you need either to explain your problem more clearly or provide the test case demonstrating the issue.