Re: boost::recursive_mutex for thread-safe logging crashing

"bill_kempf" wrote in message news:al2kli+qmrv@eGroups.com...

...

Hello:

I have a simple class to do simple thread-safe logging using recursive_mutex as shown below. The problem is, once in a while, it causes any

--- In Boost-Users@y..., "Ani Taggu" wrote: thread to die

...

while it tries to log. I haven't been able to isolate why this happens. Is recursive_mutex being used correctly?

I'm not sure I can answer why threads would "die". I'm going to assume there's an exception being thrown in the thread, but that's just a guess.

Yes the exception thrown is caught in thread_proxy() [thread.cpp] ... btw, it was difficult for me to figure out that the thread was "dying" because the exception was being caught using catch (...). Would it help if the exception was rethrown -- at least for debugging purposes? How else can I figure out if a boost::thread exited? I am not doing a "join" on the thread ...

I will comment on your logger, though. It's flawed. The stream library provided on your platform/compiler already provide the level of thread synchronization that your logger does. The problem is that this level of thread synchronization granularity is not enough. Consider your use case:

TheLog() << "Hello World" << endl;

The stream is synchronized when outputting "Hello World" and when outputting the "endl" manipulator, but not between these two seperate calls. This means your output can be interleaved, and basically be unreadable because of this. You really want to make the entire output sequence syncrhonized.

Thanks Bill. I understand this. My application is targeted for linux/gcc , solaris/SunCC and Windows/MSVC. Do stream libraries in these platforms provide the thread synchronization you mentioned?

I'm also uncertain why you'd use a recursive_mutex in this case?

Me too :). It used to be boost::mutex earlier ... then due to some thread problem (that I don't remember), I made it recursive_mutex .... it worked fine from then on (until now). Pretty weird reasoning - but time pressure is a difficult thing to handle :). I can try to reproduce the behavior when using boost::mutex ....

Bill Kempf