RE: [boost] thread safety in boost date time

From: Yitzhak Sapir (yitzhak.sapir_at_[hidden])
Date: 2005-03-13 05:43:37

Regarding the thread safety issue relating to getenv() in
boost date_time, we have now identified the problem and 
it appears to be a call to putenv() elsewhere in log4cxx.
putenv() is usually not bad, but here there is a call to
putenv() with a string created on the stack.  When the
thread ends, the stack gets destroyed and further calls
to getenv() cause an access violation.  So the bug was
not thread safety, but simply an ugly bug in log4cxx.

However, the fact remains that the date_time library
uses non-thread safe functions in a way that cannot be
controlled by the user.  boost date_time may not be the
only one calling these functions, and so "wrap it in a mutex
on your side" requires the user to know which calls to wrap
in a mutex, and be sure that all third parties, not just boost
but also log4cxx etc.,  using "localtime" are wrapped in the
same mutex.  And this assumes that all that is necessary
to solve the thread safety in some implementation of
"localtime" is to call "localtime" serially and never
concurrently.  This is operating system dependent and one
of the reasons to use boost is to eliminate os-dependent
code.  log4cxx has fixed this already in its cvs due to a 
rewrite of the framework.  When I mentioned it should be
in a central place, this is because there are various
libraries, such as spirit, that require (or required -- we're using
1.30.2) BOOST_SPIRIT_THREAD_SAFE to be defined, and so
it would be nice if all "what you need to do to work in multi-
threaded environments" was all in one central place, rather than
forcing the user to collect bits of information on this issue from
each of the various libraries.

Yitzhak Sapir