Blog Archive for / cplusplus /

November 2009 C++ Standards Committee Mailing

Tuesday, 17 November 2009

The November 2009 mailing for the C++ Standards Committee was published last week. This is the post-meeting mailing for the October committee meeting and contains a new working draft incorporating all the proposals accepted at the October meeting.

As those of you who read Herb Sutter's blog or Michael Wong's blog will already know, the big news for concurrency is that a proposal for std::async has been accepted, and this is reflected in the latest working draft.

There are 5 concurrency-related papers (of which my name is on one), which I summarize below:

Concurrency-related papers

N2985: C and C++ Thread Compatibility

Lawrence Crowl has been through the concurrency and multithreading support from the C++ working draft, and compared this to that now being added to the C working draft for the next C standard. This paper contains his observations and recommendations about the potential for compatibility between the types and functions provided by the two draft standards. I agree with some of his recommendations, and disagree with others. No action will be taken by the C++ committee unless his recommendations become full proposals.

N2992: More Collected Issues with Atomics

This is Lawrence Crowl's paper which rounds up various issues with the C++ atomics. It was accepted by the committee, and has been incorporated into the working draft. The most noticeable change is that the atomic types and functions now live in the <atomic> header. The macro for identifying lock-free atomics has been expanded into a set of macros, one per type, and a guarantee has been added that all instances of a type are lock-free, or all are not lock-free (rather than it being allowed to vary between objects). There is also a clarification that if you use compare-exchange operations on a type with padding bits then the padding bits will be part of the comparison (which will therefore affect atomic<float> or similar), plus a few other clarifications.

N2996: A Simple Asynchronous Call

This paper is by Herb Sutter and Lawrence Crowl, and brings together their papers from the pre-meeting mailing (N2970 and N2973) based on feedback from the committee. This is the std::async proposal that got accepted, and which has been incorporated into the working draft.

The result is that we have a variadic async function with an optional launch policy as the first argument, which specifies whether the function is to be spawned on a separate thread, deferred until get() or wait() is called on the returned future, or either, at the choice of the implementation.

N2997: Issues on Futures (Rev. 1)

This is a revision of N2967 from the pre-meeting mailing, which incorporates feedback from the committee. This is the version that was accepted, and which has been incorporated into the working draft. The key change is that unique_future has been renamed to just future in order to make things easier to read in what is anticipated to be the common case.

N2999: Background for issue 887: Clocks and Condition Variables (Rev. 1)

This is a minor revision of Detlef's paper from the pre-meeting mailing (N2969). The changes it proposes have not yet been accepted into the working paper, and will make it implementation-dependent which clocks can be used for condition variable waits.

Other concurrency changes in the working draft

  • std::mutex now has a constexpr constructor, so namespace-scope objects are guaranteed to be safe from initialization order issues.
  • The return type of the wait_for and wait_until member functions of std::condition_variable and std::condition_variable_any has been changed from a bool to a cv_status enum. This makes it clear whether the return is due to a signal (or spurious wake) or because the operation timed out.

Updated implementation

Our just::thread implementation of the C++0x thread library will shortly be updated to incorporate all these changes (including an implementation of std::async). Existing customers will get a free upgrade as usual.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

September 2009 C++ Standards Committee Mailing

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:

Concurrency-related papers

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_context class, along with full proposed wording. I think this provides a workable solution to the general problem of ensuring that destructors for thread_local variables 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_future which 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_for and std::condition_variable::wait_until may 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::async function. There is a lot of discussion around the various issues, but the proposed wording seems incomplete — for example, if the unique_future associated with a synchronous async call is moved into a shared_future which 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::async function. Whilst better specified than N2970 (a "serial" task is invoked in unique_future::get() or when the unique_future is 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 async function. 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 async.

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 standard. Comment on this blog post if you've got an opinion on the matter, and I'll pass it on.

Other papers

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:

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.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

August 2009 C++ Standards Committee Mailing

Thursday, 06 August 2009

The August 2009 mailing for the C++ Standards Committee was published yestoday. This is the post-meeting mailing for the July committee meeting. There isn't a new working draft this time, for one very simple reason: the "Concepts" feature was voted out of C++0x, so huge sections of the draft will have to be changed. Thankfully, the concurrency-related parts had not yet had concepts applied, so will not be affected directly by this.

C++0x timetable

What does this mean for the timetable? Well, the committee currently intends to issue a new Committee Draft for voting and comments by National Bodies in March 2010. How long it takes to get from that draft to a new Standard will depend on the comments that come back, and the length of the committee's issue lists. This is not intended to be a Final Committee Draft, implying there would be at least one more round of voting and comments. As I understand it, the earliest we could get a new Standard is thus early 2011, though if that were to be the case then the details would be finalised late 2010.

Concurrency-related papers

This time, there's only one concurrency-related paper in the mailing:

N2925: More Collected Issues with Atomics

This paper gathers together the proposed wording for a number of outstanding issues with respect to the atomic data types. This tightens up the wording regards the memory ordering guarantees of fences, and adjusts the overload set for both free functions and member functions to ensure atomics behave sensibly in more circumstances. Crucially, the header for atomic operations is also changed — rather than the <cstdatomic> / <stdatomic.h> pairing from the previous draft there is a single header: <atomic>.

Future developments

Though futures were discussed, no change was made to the working paper in this regard. Detlef and I have been asked to write a further paper on the topic to incorporate the issues raised at the meeting, which will therefore be in the next committee mailing.

Likewise, the proposals for dealing with the lifetime of thread_local variables and for launching an asynchronous task with a return value are still under discussion, and further papers on those can be expected.

Your input

How do you feel about the removal of concepts? Do you think the slip in schedule will have an impact on you? Let me know in the comments.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

June 2009 C++ Standards Committee Mailing - New Working Draft and Concurrency Papers

Wednesday, 24 June 2009

The June 2009 mailing for the C++ Standards Committee was published today. This is the pre-meeting mailing for the upcoming committee meeting. Not only does it include the current C++0x working draft, but there are 39 other papers, of which 6 are concurrency related.

Concurrency-related papers

N2880: C++ object lifetime interactions with the threads API

This is a repeat of the same paper from the May 2009 mailing. It is referenced by several of the other concurrency papers.

N2888: Moving Futures - Proposed Wording for UK comments 335, 336, 337 and 338

This is the first of my papers in this mailing. The current working draft restricts std::unique_future to be MoveConstructible, but not MoveAssignable. It also restricts std::shared_future in a similar way, by making it CopyConstructible, but not CopyAssignable. This severely limits the potential use of such futures, so the UK panel filed comments on CD1 such as UK comment 335 which requested relaxation of these unnecessary restrictions. This paper to provide a detailed rationale for these changes, along with proposed wording.

N2889: An Asynchronous Call for C++

This is the first of two papers in the mailing that proposes a std::async() function for starting a task possibly asynchronously and returning a future for the result from that task. This addresses a need identified by UK comment 329 on CD1 for a simple way of starting a task with a return value asynchronously.

N2901: A simple async()

This is the second of the papers in the mailing that proposes a std::async() function for starting a task possibly asynchronously and returning a future for the result from that task.

The primary difference between the papers is the type of the returned future. N2889 proposes a new type of future (joining_future), whereas N2901 proposes using std::unique_future. There are also a few semantic differences surrounding whether tasks that run asynchronously aways do so on a new thread, or whether they may run on a thread that is reused for multiple tasks. Both papers provide a means for the caller to specify synchronous execution of tasks, or to allow the implementation to decide between synchronous execution and asynchronous execution on a case-by-case basis. N2901 also explicitly relies on the use of lambda functions or std::bind to bind parameters to a call, whereas N2889 supports specifying function arguments as additional parameters, as per the std::thread constructor (see my introduction to starting threads with arguments in C++0x).

Personally, I prefer the use of std::unique_future proposed in N2901, but I rather like the argument-passing semantics of N2889. I also think that the thread_local issues can be addressed by my proposal for that (N2907, see below). A final concern that I have is that calling the task inside future::get() can yield surprising behaviour, as futures can be passed across threads, so this may end up being called on another thread altogether. For synchronous execution, I would prefer invoking the task inside the std::async call itself, but delaying it to the get() does allow for work-stealing thread pools.

N2907: Managing the lifetime of thread_local variables with contexts

This is the second of my papers in this mailing. It proposes a potential solution to the lifetime-of-thread_local-variables issues from N2880 discussed in last month's blog post.

The idea is that you manage the lifetime of thread_local variables by constructing an instance of a new class std::thread_local_context. When the std::thread_local_context instance is destroyed, all thread_local variables created in that context are also destroyed. You can then construct a subsequent instance of std::thread_local_context, and create new thread_local instances in that new context. This means that you can reuse a thread for multiple unrelated tasks, without "spilling" thread_local variables from an earlier task into later tasks. It can also be used with a std::async() function to ensure that the thread_local variables are destroyed before the associated future is made ready.

N2917: N2880 Distilled, and a New Issue With Function Statics

This is Herb Sutter's take on the issues from N2880. He starts with a general discussion of the issue with detached threads and static destruction of globals, and then continues with a discussion of the issues surrounding the destruction of function-scoped thread_local variables. In particular, Herb focuses on something he calls Function thread_local statics poisoning thread_local destructors — if the destructor of a thread_local object x calls a function that itself uses a function-scope thread_local y, then the destructor of y might already have been called, resulting in undefined behaviour.

I found Herb's coverage of the issues surrounding detached threads dismissive of the idea that people could correctly write manual synchronization (e.g. using a std::condition_variable or a std::unique_future), even though this is common practice amongst those using POSIX threads (for example, in David Butenhof's Programming with POSIX Threads, he says "pthread_join is a convenience, not a rule", and describes examples using detached threads and condition variables to signal when the thread is done). I can see many possibilities for such usage, so as a consequence, I am personally in favour of his "solution" 1D: leave things as they are with regard to detached threads — it is already undefined behaviour to access something after its destruction.

However, the issue Herb raises with regard to order of destruction for thread_local variables is important, and not something that my std::thread_local_context proposal addresses. As Herb points out, the problem does exist with regard to function-local static variables already — thread_local just amplifies the problem. I am inclined to go with what POSIX threads does, and what boost::thread_specific_ptr does: make them "phoenix" variables that are re-initialized when accessed after destruction, and are thus added back onto the destructor list. This is Herb's solution 2B.

Other papers

Now that CD1 is out, and the committee is trying to get things pinned down for CD2, Concepts are getting a lot of discussion. There are therefore several papers on Concepts in the mailing. There are also papers on automatically defining move constructors, revised wording for lambdas, a proposal for unifying the function syntax, and several others. Check out the full list of papers for details.

Your comments

Do you have any comments on the papers (especially the concurrency ones, but if you have any comments on the others I'd like to know too)? Which std::async proposal do you prefer, or do you like aspects of both or neither? Do you think that thread_local_context objects combined with resurrecting thread_local objects on post-destruction access solves the thread_local issues?

Let me know by posting a comment.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

May 2009 C++ Standards Committee Mailing - Object Lifetimes and Threads

Monday, 18 May 2009

The May 2009 mailing for the C++ Standards Committee was published a couple of weeks ago. This is a minimal mailing between meetings, and only has a small number of papers.

The primary reason I'm mentioning it is because one of the papers is concurrency related: N2880: C++ object lifetime interactions with the threads API by Hans-J. Boehm and Lawrence Crowl. Hans and Lawrence are concerned about the implications of thread_local objects with destructors, and how you can safely clean up threads if you don't call join(). The issue arose during discussion of the proposed async() function, but is generally applicable.

thread_local variables and detached threads

Suppose you run a function on a thread for which you want the return value. You might be tempted to use std::packaged_task<> and std::unique_future<> for this; after all it's almost exactly what they're designed for:

#include <thread>
#include <future>
#include <iostream>

int find_the_answer_to_LtUaE();

std::unique_future<int> start_deep_thought()
{
    std::packaged_task<int()> task(find_the_answer_to_LtUaE);
    std::unique_future<int> future=task.get_future();
    std::thread t(std::move(task));
    t.detach();
    return future;
}

int main()
{
    std::unique_future<int> the_answer=start_deep_thought();
    do_stuff();
    std::cout<<"The answer="<<the_answer.get()<<std::endl;
}

The call to get() will wait for the task to finish, but not the thread. If there are no thread_local variable this is not a problem — the thread is detached so the library will clean up the resources assigned to it automatically. If there are thread_local variables (used in find_the_answer_to_LtUaE() for example), then this does cause a problem, because their destructors are not guaranteed to complete when get() returns. Consequently, the program may exit before the destructors of the thread_local variables have completed, and we have a race condition.

This race condition is particularly problematic if the thread accesses any objects of static storage duration, such as global variables. The program is exiting, so these are being destroyed; if the thread_local destructors in the still-running thread access global variables that have already been destroyed then your program has undefined behaviour.

This isn't the only problem that Hans and Lawrence discuss — they also discuss problems with thread_local and threads that are reused for multiple tasks — but I think it's the most important issue.

Solutions?

None of the solutions proposed in the paper are ideal. I particularly dislike the proposed removal of the detach() member function from std::thread. If you can't detach a thread directly then it makes functions like start_deep_thought() much harder to write, and people will find ways to simulate detached threads another way. Of the options presented, my preferred choice is to allow registration of a thread termination handler which is run after all thread_local objects have been destroyed. This handler can then be used to set the value on a future or notify a condition variable. However, it would make start_deep_thought() more complicated, as std::packaged_task<> wouldn't automatically make use of this mechanism unless it was extended to do so — if it did this every time then it would make it unusable in other contexts.

If anyone has any suggestions on how to handle the issue, please leave them in the comments below and I'll pass them on to the rest of the committee.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

March 2009 C++ Standards Committee Mailing - New C++0x Working Paper, Concurrency Changes

Monday, 30 March 2009

The March 2009 mailing for the C++ Standards Committee was published last week. This mailing contains the results of the first round of National Body voting on the C++0x draft, as well as the latest version of the C++0x working draft. This latest draft includes some changes in response to these NB comments, as agreed at the committee meeting at the beginning of March. Some of the changes related to concurrency and the thread library are listed below. The state of all comments (accepted, rejected, or unprocessed) can be found in N2863: C++ CD1 comment status.

The committee is intending to address all the comments (which may include rejecting some, as has already happened) in time to publish a second draft for National Body comments by the end of the year. If there is sufficient consensus on that draft, it will become the C++0x standard, otherwise it will have to undergo another round of revisions.

Concurrency-related Changes

The atomics library has only seen one accepted change so far, and that's a result of US issue 91: a failed compare_exchange operation is only atomic load rather than a read-modify-write operation. This should not have any impact on code that uses atomics, but can enable the implementation to be optimized on some architectures. The details can be seen in LWG issue 1043.

On the other hand, the thread library has seen a couple of accepted changes which will have user-visible consequences. These are:

std::thread destructor calls std::terminate() instead of detach()
Hans Boehm's paper N2082: A plea to reconsider detach-on-destruction for thread objects, was reviewed as part of US issue 97. The result is that if you do not explicitly call join() or detach() on your std::thread objects before they are destroyed then the library will call std::terminate(). This is to ensure that there are no unintentional "dangling threads" with references to local variables.
std::thread and std::unique_lock no longer have swap() functions that operate on rvalues
This change is in response to US issue 46, and the associated paper N2844: Fixing a Safety Problem with Rvalue References: Proposed Wording (Revision 1), which changes the way the rvalue-references work. In particular, an rvalue-reference no longer binds to an lvalue. Combined with the previous change to disallow destroying std::thread objects with an associated thread of execution this makes perfect sense: swapping two rvalue std::thread objects serves no purpose anyway, and swapping a std::thread variable with an rvalue would now call std::terminate() when the rvalue is destroyed at the end of the expression, if the variable had an associated thread of execution.
The single-argument std::thread constructor has been removed
This was UK issue 323. The variadic std::thread constructor provides all the necessary functionality.

There are also a few minor concurrency-related changes that have been approved, mostly along the lines of clarifying the text. There are a few more which are still under discussion, one of which is quite significant: UK issue 329. This comment proposes the addition of a new function std::async() which will execute a function asynchronously and return a std::unique_future which can be used to obtain the result. Details can be seen under LWG issue 1043.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

Rvalue References and Perfect Forwarding in C++0x

Wednesday, 03 December 2008

One of the new features in C++0x is the rvalue reference. Whereas the a "normal" lvalue reference is declared with a single ampersand &, an rvalue reference is declared with two ampersands: &&. The key difference is of course that an rvalue reference can bind to an rvalue, whereas a non-const lvalue reference cannot. This is primarily used to support move semantics for expensive-to-copy objects:

class X
{
    std::vector<double> data;
public:
    X():
        data(100000) // lots of data
    {}
    X(X const& other): // copy constructor
        data(other.data)   // duplicate all that data
    {}

    X(X&& other):  // move constructor
        data(std::move(other.data)) // move the data: no copies
    {}

    X& operator=(X const& other) // copy-assignment
    {
        data=other.data; // copy all the data
        return *this;
    }

    X& operator=(X && other) // move-assignment
    {
        data=std::move(other.data); // move the data: no copies
        return *this;
    }

};

X make_x(); // build an X with some data

int main()
{
    X x1;
    X x2(x1); // copy
    X x3(std::move(x1)); // move: x1 no longer has any data

    x1=make_x(); // return value is an rvalue, so move rather than copy
}

Though move semantics are powerful, rvalue references offer more than that.

Perfect Forwarding

When you combine rvalue references with function templates you get an interesting interaction: if the type of a function parameter is an rvalue reference to a template type parameter then the type parameter is deduce to be an lvalue reference if an lvalue is passed, and a plain type otherwise. This sounds complicated, so lets look at an example:

template<typename T>
void f(T&& t);

int main()
{
    X x;
    f(x);   // 1
    f(X()); // 2
}

The function template f meets our criterion above, so in the call f(x) at the line marked "1", the template parameter T is deduced to be X&, whereas in the line marked "2", the supplied parameter is an rvalue (because it's a temporary), so T is deduced to be X.

Why is this useful? Well, it means that a function template can pass its arguments through to another function whilst retaining the lvalue/rvalue nature of the function arguments by using std::forward. This is called "perfect forwarding", avoids excessive copying, and avoids the template author having to write multiple overloads for lvalue and rvalue references. Let's look at an example:

void g(X&& t); // A
void g(X& t);      // B

template<typename T>
void f(T&& t)
{
    g(std::forward<T>(t));
}

void h(X&& t)
{
    g(t);
}

int main()
{
    X x;
    f(x);   // 1
    f(X()); // 2
    h(x);
    h(X()); // 3
}

This time our function f forwards its argument to a function g which is overloaded for lvalue and rvalue references to an X object. g will therefore accept lvalues and rvalues alike, but overload resolution will bind to a different function in each case.

At line "1", we pass a named X object to f, so T is deduced to be an lvalue reference: X&, as we saw above. When T is an lvalue reference, std::forward<T> is a no-op: it just returns its argument. We therefore call the overload of g that takes an lvalue reference (line B).

At line "2", we pass a temporary to f, so T is just plain X. In this case, std::forward<T>(t) is equivalent to static_cast<T&&>(t): it ensures that the argument is forwarded as an rvalue reference. This means that the overload of g that takes an rvalue reference is selected (line A).

This is called perfect forwarding because the same overload of g is selected as if the same argument was supplied to g directly. It is essential for library features such as std::function and std::thread which pass arguments to another (user supplied) function.

Note that this is unique to template functions: we can't do this with a non-template function such as h, since we don't know whether the supplied argument is an lvalue or an rvalue. Within a function that takes its arguments as rvalue references, the named parameter is treated as an lvalue reference. Consequently the call to g(t) from h always calls the lvalue overload. If we changed the call to g(std::forward<X>(t)) then it would always call the rvalue-reference overload. The only way to do this with "normal" functions is to create two overloads: one for lvalues and one for rvalues.

Now imagine that we remove the overload of g for rvalue references (delete line A). Calling f with an rvalue (line 2) will now fail to compile because you can't call g with an rvalue. On the other hand, our call to h with an rvalue (line 3) will still compile however, since it always calls the lvalue-reference overload of g. This can lead to interesting problems if g stores the reference for later use.

Further Reading

For more information, I suggest reading the accepted rvalue reference paper and "A Brief Introduction to Rvalue References", as well as the current C++0x working draft.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

October 2008 C++ Standards Committee Mailing - New C++0x Working Paper, More Concurrency Papers Approved

Wednesday, 08 October 2008

The October 2008 mailing for the C++ Standards Committee was published today. This is a really important mailing, as it contains the latest edition of the C++0x Working Draft, which was put out as a formal Committee Draft at the September 2008 meeting. This means it is up for formal National Body voting and comments, and could in principle be the text of C++0x. Of course, there are still many issues with the draft and it will not be approved as-is, but it is "feature complete": if a feature is not in this draft it will not be in C++0x. The committee intends to fix the issues and have a final draft ready by this time next year.

Concurrency Papers

As usual, there's a number of concurrency-related papers that have been incorporated into the working draft. Some of these are from this mailing, and some from prior mailings. Let's take a look at each in turn:

N2752: Proposed Text for Bidirectional Fences
This paper modifies the wording for the use of fences in C++0x. It is a new revision of N2731: Proposed Text for Bidirectional Fences, and is the version voted into the working paper. Now this paper has been accepted, fences are no longer tied to specific atomic variables, but are represented by the free functions std::atomic_thread_fence() and std::atomic_signal_fence(). This brings C++0x more in line with current CPU instruction sets, where fences are generally separate instructions with no associated object. std::atomic_signal_fence() just restricts the compiler's freedom to reorder variable accesses, whereas std::atomic_thread_fence() will typically also cause the compiler to emit the specific synchronization instructions necessary to enforce the desired memory ordering.
N2782: C++ Data-Dependency Ordering: Function Annotation
This is a revision of N2643: C++ Data-Dependency Ordering: Function Annotation, and is the final version voted in to the working paper. It allows functions to be annotated with [[carries_dependency]] (using the just-accepted attributes proposal) on their parameters and return value. This can allow implementations to better-optimize code that uses std::memory_order_consume memory ordering.
N2783: Collected Issues with Atomics
This paper resolves LWG issues 818, 845, 846 and 864. This rewords the descriptions of the memory ordering values to make it clear what they mean, removes the explicit qualification on the std::atomic_xxx constructors to allow implicit conversion on construction (and thus allow aggregate-style initialization), and adds simple definitions of the constructors for the atomic types (which were omitted by accident).
N2668: Concurrency Modifications to Basic String
This has been under discussion for a while, but was finally approved at the September meeting. The changes in this paper ensure that it is safe for two threads to access the same std::string object at the same time, provided they both perform only read operations. They also ensure that copying a string object and then modifying that copy is safe, even if another thread is accessing the original. This essentially disallows copy-on-write implementations since the benefits are now severely limited.
N2748: Strong Compare and Exchange
This paper was in the previous mailing, and has now been approved. In the previous working paper, the atomic compare_exchange functions were allowed to fail "spuriously" even when the value of the object was equal to the comparand. This allows efficient implementation on a wider variety of platforms than otherwise, but also requires almost all uses of compare_exchange to be put in a loop. Now this paper has been accepted, instead we provide two variants: compare_exchange_weak and compare_exchange_strong. The weak variant allows spurious failure, whereas the strong variant is not allowed to fail spuriously. On architectures which provide the strong variant by default (such as x86) this would remove the need for a loop in some cases.
N2760: Input/Output Library Thread Safety
This paper clarifies that unsynchronized access to I/O streams from multiple threads is a data race. For most streams this means the user is responsible for providing this synchronization. However, for the standard stream objects (std::cin, std::cout, std::cerr and friends) such external synchronization is only necessary if the user has called std::ios_base::sync_with_stdio(false).
N2775: Small library thread-safety revisions
This short paper clarifies that the standard library functions may only access the data and call the functions that they are specified to do. This makes it easier to identify and eliminate potential data races when using standard library functions.
N2671: An Asynchronous Future Value: Proposed Wording
Futures are finally in C++0x! This paper from the June 2008 mailing gives us std::unique_future<>, std::shared_future<> and std::promise<>, which can be used for transferring the results of operations safely between threads.
N2709: Packaging Tasks for Asynchronous Execution
Packaged Tasks are also in C++0x! This is my paper from the July 2008 mailing, which is the counterpart to N2671. A std::packaged_task<F> is very similar to a std::function<F> except that rather than returning the result directly when it is invoked, the result is stored in the associated futures. This makes it easy to spawn functions with return values on threads, and provides a building block for thread pools.

Other Changes

The biggest change to the C++0x working paper is of course the acceptance of Concepts. There necessary changes are spread over a staggering 14 Concepts-related papers, all of which were voted in to the working draft at the September 2008 meeting.

C++0x now also has support for user-defined literals (N2765: User-defined Literals (aka. Extensible Literals (revision 5))), for default values of non-static data members to be defined in the class definition (N2756: Non-static data member initializers), and forward declaration of enums (N2764: Forward declaration of enumerations (rev. 3)).

Get Involved: Comment on the C++0x Draft

Please read the latest C++0x Working Draft and comment on it. If you post comments on this blog entry I'll see that the committee gets to see them, but I strongly urge you to get involved with your National Body: the only changes allowed to C++0x now are in response to official National Body comments. If you're in the UK, contact me and I'll put you in touch with the relevant people on the BSI panel.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

C++0x Draft and Concurrency Papers in the August 2008 Mailing

Thursday, 28 August 2008

Yesterday, the August 2008 C++ Standards Committee Mailing was published. This features a new Working Draft for C++0x, as well as quite a few other papers.

Thread-local storage

This draft incorporates N2659: Thread-Local Storage, which was voted in at the June committee meeting. This introduces a new keyword: thread_local which can be used to indicate that each thread will have its own copy of an object which would otherwise have static storage duration.

thread_local int global;
thread_local std::string constructors_allowed;

void foo()
{
    struct my_class{};

    static thread_local my_class block_scope_static;
}

As the example above shows, objects with constructors and destructors can be declared thread_local. The constructor is called (or other initialization done) before the first use of such an object by a given thread. If the object is used on a given thread then it is destroyed (and its destructor run) at thread exit. This is a change from most common pre-C++0x implementations, which exclude objects with constructors and destructors.

Additional concurrency papers

This mailing contains several papers related to concurrency and multithreading in C++0x. Some are just rationale or comments, whilst others are proposals which may well therefore be voted into the working draft at the September meeting. The papers are listed in numerical order.

N2731: Proposed Text for Bidirectional Fences
This is a revised version of N2633: Improved support for bidirectional fences, which incorporates naming changes requested by the committee at the June meeting, along with some modifications to the memory model. In particular, read-modify-write operations (such as exchange or fetch_add) that use the memory_order_relaxed ordering can now feature as part of a release sequence, thus increasing the possibilities for using memory_order_relaxed operations in lock-free code. Also, the definition of how fences that use memory_order_seq_cst interact with other memory_order_seq_cst operations has been clarified.
N2744: Comments on Asynchronous Future Value Proposal
This paper is a critique of N2671: An Asynchronous Future Value: Proposed Wording. In short, the suggestions are:
  • that shared_future<T>::get() should return by value rather than by const reference;
  • that promise objects are copyable;
  • and that the promise functions for setting the value and exception be overloaded with versions that return an error code rather than throwing an exception on failure.
N2745: Example POWER Implementation for C/C++ Memory Model
This paper discusses how the C++0x memory model and atomic operations can be implemented on systems based on the POWER architecture. As a consequence, this also shows how the different memory orderings can affect the actual generated code for atomic operations.
N2746: Rationale for the C++ working paper definition of "memory location"
This paper is exactly what it says: a rationale for the definition of "memory location". Basically, it discusses the reasons why every object (even those of type char) is a separate memory location, even though this therefore requires that memory be byte-addressable, and restricts optimizations on some architectures.
N2748: Strong Compare and Exchange
In the current working paper, the atomic compare_exchange functions are allowed to fail "spuriously" even when the value of the object was equal to the comparand. This allows efficient implementation on a wider variety of platforms than otherwise, but also requires almost all uses of compare_exchange to be put in a loop. This paper proposes that instead we provide two variants: compare_exchange_weak and compare_exchange_strong. The weak variant would be the same as the current version, whereas the strong variant would not be allowed to fail spuriously. On architectures which provide the strong variant by default (such as x86) this would remove the need for a loop in some cases.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

July 2008 C++ Standards Committee Mailing Published

Wednesday, 30 July 2008

The July 2008 mailing for the C++ Standards Committee was published today. Primarily this is just an update on the "state of evolution" papers, and the issue lists. However, there are a couple of new and revised papers. Amongst them is my revised paper on packaged_task: N2709: Packaging Tasks for Asynchronous Execution.

As I mentioned when the most recent C++0x draft was published, futures are still under discussion, and the LWG requested that packaged_task be moved to a separate paper, with a few minor changes. N2709 is this separate paper. Hopefully the LWG will approve this paper at the September meeting of the C++ committee in San Francisco; if they don't, then packaged_task will join the long list of proposals that have missed the boat for C++0x.

Posted by Anthony Williams
[/ cplusplus /] permanent link
Tags: , ,

| Stumble It! stumbleupon logo | Submit to Reddit reddit logo | Submit to DZone dzone logo

Comment on this post

If you liked this post, why not subscribe to the RSS feed RSS feed or Follow me on Twitter? You can also subscribe to this blog by email using the form on the right.

More recent entries Older entries