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

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-09-03 16:00:31

--- In Boost-Users_at_y..., "Ani Taggu" <yg-boost-users_at_m...> wrote:
> 
> "bill_kempf" <williamkempf_at_h...> wrote in message
> news:al2kli+qmrv_at_e...
> > --- In Boost-Users_at_y..., "Ani Taggu" <yg-boost-users_at_m...> wrote:
> > > 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
> > 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
> ...

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.

> > 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?

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