Dear all, I got a compiler(gcc 3.4.5) error while using boost.thread. The following is my code: ----------------------------------------------------------------------------------------------------------------------------- #include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <iostream> boost::mutex io_mutex; void count(int id) { boost::mutex::scoped_lock lock(io_mutex,false); for (int i = 0; i < 10; ++i) { lock.lock(); std::cout << id << ": " << i << std::endl; lock.unlock(); } } int main(int argc, char* argv[]) { boost::thread thrd1(count, 1); boost::thread thrd2(count, 2); thrd1.join(); thrd2.join(); return 0; } ----------------------------------------------------------------------------- I know I can just abandon the lock() and unlock() function since the constructor and destructor will do them for me. But I can't understand how this error occurs and why the compiler has something to do with basic_timed_mutex. Anyone can give me some clues? Thanks in advance.
On Mar 20, 2010, at 1:16 AM, weii wrote:
I got a compiler(gcc 3.4.5) error while using boost.thread.
The following is my code: ----------------------------------------------------------------------------------------------------------------------------- #include <boost/thread/thread.hpp> #include <boost/thread/mutex.hpp> #include <boost/bind.hpp> #include <iostream>
boost::mutex io_mutex;
void count(int id) { boost::mutex::scoped_lock lock(io_mutex,false);
The problem is the second argument in the lock construct. The old mechanism of constructing an unlocked lock went away in (I think) boost 1.35. I don't remember how it gets there, but the I do remember (from cleaning up a bunch of explicit and unnecessary true second arguments in some code I inherited) that the failure was reporting something about timed_mutex.
The problem is the second argument in the lock construct. The old mechanism of constructing an unlocked lock went away in (I think) boost 1.35. Yeah, I'm using boost 1.40. I don't remember how it gets there, but the I do remember (from cleaning up a bunch of explicit and unnecessary true second arguments in some code I inherited) that the failure was reporting something about timed_mutex.
Thank you very much.
participants (2)
-
Kim Barrett
-
weii