Standard Library problems w/multi-threading

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-09-10 15:48:28

Several C++ Standard Library functions (all inherited from C) are 
particular problems for implementors thread-safe versions of the Standard 
Library because they hold internal state between calls:

     rand
     strtok
     asctime
     ctime
     gmtime
     localtime

It is actually possible to write thread-safe implementations of these by 
using thread-specific storage; several C++ compiler vendor's 
implementations do so - the technique is well-know and is explained in 
Butenhoff's book.

But at least one vendor (HP-UX) chose not to provide thread-safe versions 
of the above functions in their otherwise thread-safe runtime 
library.  Instead they provide reentrant versions, with additional 
arguments to workaround the internal state issues:

     rand_r
     strtok_r
     asctime_r
     ctime_r
     gmtime_r
     localtime_r

These are based on a POSIX spec I'm guessing.

So what should we do so users of Boost.Threads can write portable code?

*  Just warn users, and let them deal with having to use say asctime() in 
some implementations and asctime_r() in other.  (This is a poor solution, 
IMO, as it will certainly result in porting bugs only detected painfully 
when programs fail.)

*  Provide a default implementation of the above set of xxx_r functions, 
following the POSIX spec, and warn users to avoid the Standard Library 
functions.

*  Provide better, thread-safe, C++ oriented solutions.  Haven't our Random 
Number and Tokenizer libraries already done that for the first two on the 
list?  (I haven't looked at the code; is it thread-safe?) So what would be 
left is a Boost time and date library, something that has been mentioned in 
the past.

Opinions?

--Beman