Boost logo

Boost :

From: Phil Endecott (spam_from_boost_dev_at_[hidden])
Date: 2007-10-08 12:51:59

Jeff Garland wrote:
> At the Kona meeting (just finished) the standard committee made very
> significant progress on threading for C++0x -- voting in a proposal written by
> Howard H, Beman, Anthony Williams, myself, and others -- subject to wording
> changes to be made by a small drafting committee. Basically we were in
> agreement on semantics, but even after several late night drafting sessions
> people weren't happy with the standardeze.
> While much of the proposal is based on Boost.thread it has some serious
> departures in the way mutexes and guard interfaces work, it's use of date-time
> types for clock/timing interfaces and such.

This reminds me: 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.
This reminded me of some presentations about power saving at
LinuxConf.EU: apparently reducing the number of timer interrupts is
greatly beneficial to increasing energy efficiency, and one way to
achieve this is to align all applications' periodic wakeups. Very
often, we want to timeout after "about a second" but will actually
specify a timeout value of "exactly 1.0000000 seconds"; if the API
allowed us to indicate, for example, "between 0.1 and 1.5 seconds", or
"1 second +/- 10%", then some hidden power-saving wakeup-alignment
algorithm could be applied. (Equally, you could imagine situations
where it would be beneficial to spread out wakeups, rather than
grouping them.) So does the proposal allow this sort of thing to be
done, by supplying a "time range" type?

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.

Any thoughts?



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