Boost C++ Libraries: Ticket #5034: boost::this_thread::sleep either returns instantaneously or spins

Tue, 04 Jan 2011 16:41:26 GMT

When I see the 'spinning' I can grab the following back trace - which doesn't say much but points to the issue being in the timed_wait(), see frame 3.

#0  0x00007ffff7bcbf05 in __pthread_mutex_lock (mutex=0xcf8d00) at pthread_mutex_lock.c:61
#1  0x00000000008bc1c5 in boost::mutex::lock (this=0xcf8d00)
    at /thirdparty/boost/boost_1_45/source/boost/thread/pthread/mutex.hpp:52
#2  0x00000000009d3d76 in boost::unique_lock<boost::mutex>::lock() ()
#3  0x00000000009f3bf9 in boost::condition_variable::timed_wait(boost::unique_lock<boost::mutex>&, boost::posix_time::ptime const&) ()
#4  0x00000000009f2b86 in boost::this_thread::sleep(boost::posix_time::ptime const&) ()
#5  0x00000000008e68a1 in boost::this_thread::sleep<boost::posix_time::seconds> (rel_time=...)
    at /thirdparty/boost/boost_1_45/source/boost/thread/pthread/thread_data.hpp:138

I still don't have a small enough test case to post but thought at least the back trace would help. To summarise then it seems that there is an issue with the timed_wait(). Either I see it return immediately or spin.

It should also be noted that the call to boost::this_thread::sleep() occurs once only in a single thread, in my case the main thread.

cc set

Chris Newbold — Wed, 05 Jan 2011 18:30:08 GMT

cc cnewbold@… added

Thu, 27 Jan 2011 13:17:19 GMT

I should add here that I tried this with a debug build of boost thread and could not get any better back trace. I also suspect this is a 64-bit only problem since others have reported no issues on 32-bit builds.

status changed; resolution set

Anthony Williams — Thu, 27 Jan 2011 14:05:38 GMT

status new → closed
resolution → worksforme

I cannot reproduce this problem on 64-bit Ubuntu 10.10

anonymous — Mon, 14 Feb 2011 10:59:30 GMT

Similar problem was described here http://lists.boost.org/boost-users/2010/10/63635.php I can reproduce it easily on Linux.

Tue, 22 Feb 2011 23:21:34 GMT

Can you be more specific about how you reproduce this on Linux? What compile flags you use and on what distribution and architecture? I think this ticket clearly needs re-opened.

storm@… — Fri, 24 Jun 2011 01:50:34 GMT

I see the same exact problem on ubuntu 32bit, on virtualbox (mac host), but it happens ONLY when I run the program in gdb.

Spawning 4 thread, each one cycling and sleeping for up to one second between any cycle, I always get 1 or 2 threads that never exit from the sleep.

Part of code:

	...
	cout << "Updater started with id " << boost::this_thread::get_id() << endl;
	while (true) {
		/* do things */
		// Throttle
		elapsed = boost::posix_time::microsec_clock::universal_time() - this->last_update;
		sleep_for = interval - elapsed;
		cout << boost::this_thread::get_id() << " sleeping for " << sleep_for << endl;
		boost::this_thread::sleep(sleep_for);
		cout << boost::this_thread::get_id() << " sleeped for " << sleep_for << endl;
	}
	...

I get on console:

Updater started with id 0x8090198
Updater started with id 0x8090810
0x8090198 sleeping for 0x8090810 sleeping for 00:00:00.998689
00:00:00.997377
Updater started with id 0x8090fb0
0x8090fb0 sleeping for 00:00:00.998187
Updater started with id 0x8091378
0x8091378 sleeping for 00:00:00.998543
0x8090198 sleeped for 00:00:00.997377
0x8090198 sleeping for 00:00:00.999980
0x8090810 sleeped for 00:00:00.998689
0x8090810 sleeping for 00:00:00.999979
0x8091378 sleeped for 00:00:00.998543
0x8091378 sleeping for 00:00:00.999979
0x8090198 sleeped for 00:00:00.999980
0x8090198 sleeping for 00:00:00.999948
0x8090810 sleeped for 00:00:00.999979
0x8090810 sleeping for 00:00:00.999951
0x8091378 sleeped for 00:00:00.999979
0x8091378 sleeping for 00:00:00.999958

( 0x8090fb0 is blocked )

anonymous — Mon, 11 Jul 2011 21:27:42 GMT

I think this thread: http://lists.boost.org/boost-users/2011/07/69287.php may also describe behaviour that is indirectly related to this issue.