Ok, thank you for your reply, I have been away for a week and I am back to work, with this problem still preventing my program to work fine. To answer your question, I have only one Robot in my project (for now) and the io_service is a Robot member. I now get why the active_count goes negative when the count goes up, but now I can't figure how it can ever be incremented twice. When debugging, I see the active_count being either 0, -2147483648, OR -2147483647. In fact, even when the active_count is not ==0, the lock() call returns instantly. Any clue ? Ernest Galbrun.

Ernest Galbrun wrote:

...

I would be really grateful if someone could give me a hint about what I am doing wrong with the mutex and thread class (I am using boost 1.43, on windows XP running visual c++ 2010, the library has been built using the bjam utility).

I have a main thread that creates an object of class robot :

class Robot { private: boost::mutex tcpLock; boost::thread continuousThread; ... }

Robot k3;

this thread launches a thread that makes continuous calls to a member function of the robot. Since this function uses network ressources, I want it to be safe so i use a lock The function called is the only function in my program that uses this lock :

int Robot::sendMsg(string msg, int n, vector<string>* answer) { tcpLock.lock(); (do stuff with the tcp io service) tcpLock.unlock(); return 0; }

Of course, I also call this function from the main thread.

And I have disruptive behavior, which I don't understand.

Do you have multiple Robots? Is the io_service shared between them?

...

When debugging, I see that the 'active_count' of the tcpLock object stays negative or ==0, which seem absolutely wrong to me, but I don't understand how it could ever be anything other than 0 or 1.

The implementation indicates that the mutex is locked with the high-order bit, which means that a locked mutex will have a negative active count.

In Christ, Steven Watanabe