Re: [boost] Standard Library problems w/multi-threading

From: Ken Shaw (ken_at_[hidden])
Date: 2001-09-10 16:22:38

----- Original Message -----
From: "Beman Dawes" <bdawes_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Monday, September 10, 2001 3:48 PM
Subject: [boost] Standard Library problems w/multi-threading

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

After attempting to implement a Date/Time class several times and never
really getting a satisfactory version I would love to see a Boost library
with an eye towards eventual submission to the standards committee. If
anyone tries this I hope they will avoid the pitfalls inherit in the old C
time functions. In particular it should be possible to represent any
reasonable date and not be limited to a scale represented by the storage of
seconds since 1/1/1970.

Ken Shaw