Boost logo

Boost :

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2007-10-08 13:57:00

On Oct 8, 2007, at 12:51 PM, Phil Endecott wrote:

> I thought I posted something about this when Howard
> sent his proposal to this list, but it seems to have been lost in an
> email black-hole. Howard's code included timed operations that are
> templated on the time type, which (presumably) allows an
> implementation
> to provide versions for each of that platform's standard time types.

Fwiw, the bits that were approved in Kona have templated timed
functions. That document isn't public yet, but will be in about two
weeks. The templated functions are still missing template
requirements wording, at least in a few places, but that will be fixed
up by Bellevue. The shared/upgrade mutex parts were not reviewed in
Kona, nor considered for C++0X. Still targeting TR2 with those, and
TR2 still has a backseat priority with respect to C++0X.

> There's also the question of whether the implementation style of a
> mutex and/or its locks can somehow be chosen, e.g. between a spin-lock
> (best when the probability of contention is very low) and an
> OS-supported mutex (best when the probability of contention is
> greater). Having substantially improved the performance of shared_ptr
> on ARM-linux by moving from pthreads to an atomic-asm implementation,
> I'm considering doing the same to Boost.Threads on that platform.
> However, the distinction between locks around very short critical
> sections (e.g. a pair of variables that must be updated atomically)
> and
> longer-duration locks needs to be made somehow.

The only suggestion I have here, from a standards point of view, is
for the standard to anticipate and support user-defined mutexes/locks
in the easiest way possible so that libraries such as boost can easily
build upon the standard foundation. This philosophical foundation is
in the standard-proposed document. Whether or not we've actually
achieved this goal is a separate question. ;-)


Boost list run by bdawes at, gregod at, cpdaniel at, john at