Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-09-10 22:11:28


--- In boost_at_y..., Beman Dawes <bdawes_at_a...> wrote:
> 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.

An alternative you missed that should go right after the above:

* Provide thread safe implementations of xxx functions by utilizing
thread specific storage. These would be in the boost:: namespace to
avoid collision with standard versions.

> * 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.

I'd opt for this one in most cases, though one of the two previous
(yours and mine) options might be needed for legacy code.
 
Bill Kempf


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk