T
Torsten Mueller
I have a question related to the timed_join() method in the boost::thread
class. I had a program like this:
#include <iostream>
#include <boost/thread.hpp>
using namespace std;
class ThreadClass
{
public:
void operator () ()
{
cout << "hello" << endl;
sleep(5);
}
};
int main (int argc, char* argv[])
{
ThreadClass c;
boost::thread th(c);
if (th.timed_join(boost:osix_time::seconds(10)))
cout << "ok" << endl;
else
cout << "timeout" << endl;
return 0;
}
On my Arch Linux (gcc) this runs as expected. The timed_join() waits
until the thread terminates or the timeout is reached. I can provocate
both use cases depending on the timespan in the sleep call.
On Windows (MSVC) this doesn't work anymore, I think since boost 1.47.
It worked without any problem for years using older boost versions but
now it is like follows: After the thread is created it's run method (the
operator ()) is not called immediately but somehow later. This gives
timed_join() the opportunity to be called on a thread which still seems
not truely to be running. So timed_join() returns immediately false,
which is wrong! Then, after timed_join(), the operator () is still
called. This is unusable.
I tried to use a unique lock on a mutex to synchronize the calling and
the called thread. This reorders the function calling sequence: the
operator () is called before timed_join() is executed. So timed_join()
finds truely a running thread but returns again false. Why?
The join() method of the thread class behaves different: join() does
truely wait, even if the thread needs a lot of time to start. I think
this difference is not intended. So is this a bug in boost 1.47?
T.M.
class. I had a program like this:
#include <iostream>
#include <boost/thread.hpp>
using namespace std;
class ThreadClass
{
public:
void operator () ()
{
cout << "hello" << endl;
sleep(5);
}
};
int main (int argc, char* argv[])
{
ThreadClass c;
boost::thread th(c);
if (th.timed_join(boost:osix_time::seconds(10)))
cout << "ok" << endl;
else
cout << "timeout" << endl;
return 0;
}
On my Arch Linux (gcc) this runs as expected. The timed_join() waits
until the thread terminates or the timeout is reached. I can provocate
both use cases depending on the timespan in the sleep call.
On Windows (MSVC) this doesn't work anymore, I think since boost 1.47.
It worked without any problem for years using older boost versions but
now it is like follows: After the thread is created it's run method (the
operator ()) is not called immediately but somehow later. This gives
timed_join() the opportunity to be called on a thread which still seems
not truely to be running. So timed_join() returns immediately false,
which is wrong! Then, after timed_join(), the operator () is still
called. This is unusable.
I tried to use a unique lock on a mutex to synchronize the calling and
the called thread. This reorders the function calling sequence: the
operator () is called before timed_join() is executed. So timed_join()
finds truely a running thread but returns again false. Why?
The join() method of the thread class behaves different: join() does
truely wait, even if the thread needs a lot of time to start. I think
this difference is not intended. So is this a bug in boost 1.47?
T.M.