Tuesday, 23 February 2010
There are 5 concurrency-related papers (of which my name is on one), which I summarize below:
Managing the lifetime of
thread_localvariables with contexts (Revision 2)
This is my paper on creating contexts for
thread_localvariables. The use of such contexts allows you to control when variables that are declared as
thread_localare destroyed. It is a revision of my previous paper N2959; the primary change is that contexts can now be nested, which allows library code to use them without having to know whether or not a context is currently active.
- N3040: Various threads issues in the library (LWG 1151)
This paper by Hans Boehm seeks to address LWG issue 1151. The key issue is to ensure that it is clear which operations may constitute a data race if they run concurrently without synchronization.
- N3041: Futures and Async Cleanup
The adoption of multiple papers affecting futures and
std::asyncat the same C++ committee meeting meant that the wording ended up being unclear. Detlef Vollmann kindly volunteered to write a paper to resolve these issues, and this is it.
Unfortunately, I think that some of the wording is still unclear. I also dislike Detlef's proposal to force the
wait_untilmember functions of the future types to throw exceptions if the future was created from a call to
std::asyncwith a launch policy of
std::launch::sync. My preferred alternative is to change the return type from
boolto an enumeration with distinct values for if the future is ready, if the wait timed out, or if the future holds a deferred function from
std::launch::syncthat has not yet started. This would be similar to the current behaviour of
std::condition_variable::wait_until, which return a
launch::anyand what asyncs really might be
This is another paper from Detlef Vollmann proposing renaming
std::launch::any_sync. His rationale is that future revisions of the C++ standard may wish to add values to the
std::launchenumeration for additional types of async calls that should not be covered by
std::launch::any. Personally, I think this is a non-issue, and should be covered as and when such values are added.
- N3045: Updates to C++ Memory Model Based on Formalization
Following attempts to create a mathematical formalization of the memory model it became clear that some cases were unclear or ambiguous or did not guarantee the desired semantics. This paper proposes some changes to the wording of the memory model in order to ensure that it means what we intended it to mean.
There's several non-concurrency papers in the mailing as well as the standard set (working draft, agenda, issues lists, etc.). The most significant of these in my view is N3044 which proposes compiler-defined move constructors and assignment operators. Check the mailing for the full set.