How to use scoped_lock

[weii]

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.

[Kim Barrett]

Post by weii
I got a compiler(gcc 3.4.5) error while using boost.thread.
-----------------------------------------------------------------------------------------------------------------------------
#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.

[weii]

Post by Kim Barrett
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.

Post by Kim Barrett
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.