[Boost-users] Fwd: Some trouble using mutexes

Subject: [Boost-users] Fwd: Some trouble using mutexes
From: Ernest Galbrun (ernest.galbrun_at_[hidden])
Date: 2010-08-30 05:18:31

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
>