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