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

3 Sep 2002

      --- In Boost-Users@y..., "Ani Taggu"  wrote:
...
"bill_kempf"  wrote in message
news:al2kli+qmrv@e...
...
...
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
...
...
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
...
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
that's
the
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
...
solaris/SunCC and Windows/MSVC.  Do stream libraries in these
Hot topic, and the final design is still being debated.  Currently 
in CVS the code now explicitly calls terminate(), which should help, 
and that's likely to be what's in the next Boost release.  
Rethrowing the exception will result in platform/implementation 
behavior, so I don't think that is the correct choice.

linux/gcc ,
platforms
...
provide the thread synchronization you mentioned?
Likely... though there's absolutely no gaurantee.  Most systems that 
provide MT support will address some thread synchronization issues 
in the standard libraries, and in general this is extremely likely 
to result in this same level of synchronization granularity.  
However, since this level of granularity won't be of any help in 
insuring meaningful output, I don't think it matters.  Your design 
should be using an external mutex synchronization scheme... though 
of course it can be encapsulated in the logger's design.  Something 
along this public interface, probably:

Logger::scoped_lock lock(myLogger);
myLogger << "Hello World" << endl;

A good article on the subject of lock granularity and various 
solutions can be found at:
http://www.informit.com/content/index.asp?product_id=%7BE3967A89-
4E20-425B-BCFF-B84B6DEED6CA%7D

Bill Kempf