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. ;-) -Howard