Wednesday, 30 September 2009
The September 2009 mailing for the C++ Standards Committee was published today. This is the pre-meeting mailing for the October committee meeting and contains the first new working draft since the "Concepts" feature was voted out of C++0x in July.
There is also quite a large number of papers in this mailing, including 7 concurrency-related papers (of which my name is on 2), which I summarize below:
- N2955: Comments on the C++ Memory Model Following a Partial Formalization Attempt
Mark has been working on a formal model for parts of the C++ memory model, and has identified a few cases where the wording could be improved to clarify things.
- N2959: Managing the lifetime of thread_local variables with contexts (Revision 1)
This is a revision of my earlier paper, N2907 which expands my proposal for a
thread_local_contextclass, along with full proposed wording. I think this provides a workable solution to the general problem of ensuring that destructors for
thread_localvariables are run at particular points in the execution of a program as discussed in N2880.
- N2967: Issues on Futures
This paper that I co-authored with Detlef Vollmann provides a complete rewording for the "Futures" section of the standard (30.6). It folds the proposed changes from N2888 in with changes requested by the LWG at July's meeting (including the addition of a new future type —
atomic_futurewhich serializes all operations), and editorial comments on the earlier wording. It doesn't resolve everything — there is still some discussion over whether
unique_future::get()should return a value or a reference, for example — but it provides a sound basis for further discussion.
- N2969: Background for issue 887: Clocks and Condition Variables
Detlef argues the case that
std::condition_variable::wait_untilmay wake "too late" if the user adjusts the system clock during a wait, and suggests simplifying the overload set to match the minimum requirements of POSIX. LWG has already decided that this is Not A Defect (NAD), and I agree — there are no guarantees about how soon after the specified timeout the wait will return, and this is thus entirely a quality of implementation issue.
- N2970: A simple async() (revision 1)
This is a revision to Herb Sutter's take on a
std::asyncfunction. There is a lot of discussion around the various issues, but the proposed wording seems incomplete — for example, if the
unique_futureassociated with a
asynccall is moved into a
shared_futurewhich is then copied, which call to
get()runs the task?
- N2973: An Asynchronous Call for C++
This is a revision to Lawrence Crowl's take on a
std::asyncfunction. Whilst better specified than N2970 (a "serial" task is invoked in
unique_future::get()or when the
unique_futureis moved into a
shared_future), I'm not entirely happy with the result.
- N2974: An Analysis of Async and Futures
To aid the committee with deciding on the semantics of
std::async, Lawrence has put together this paper which outlines various options for creating futures from an
asyncfunction. He then goes on to outline the operations that we may wish to perform on those futures, and how they relate to the various options for
As you can see by the 3 papers on the issue,
std::async is a hot topic. I hope that a single coherent
design can be agreed on at Santa Cruz, and incorporated into the
on this blog post if you've got an opinion on the matter, and I'll
pass it on.
As I said at the beginning of this post, there are quite a few papers in this mailing. Other than the new working draft, there were 3 papers that piqued my interest:
- N2954: Unified Function Syntax which proposes allowing lambda-style syntax for normal functions,
- N2953: Defining Move Special Member Functions which covers the implicit generation of move constructors and move assignment operators, and
forward which covers the usage and constraints on
Other papers include changes to the allocator proposals, papers to cover specific core issues, a couple of papers on type traits and a couple on pairs and tuples. See the full paper list for further details.