Clearspace Server Syndication Feed

Draft Specification of Transactional Language Constructs for C++

Michael_Wong — Thu, 06 Aug 2009 16:54:35 GMT

Hello all, over the last year, a group of Transactional Memory experts from Sun, Intel, and IBM have been getting together every Friday to discuss how to create a uniform syntax for Transactional Memory.

We are happy to release the first version of the Draft Specification of Transactional Language Constructs for C++. This specification is the result of a joint work by a group of people from Intel, IBM and Sun, and is based on our experience working with transactional language constructs. We would like to encourage people to implement this specification and we welcome feedback on the document. Please direct any such feedback to this discussion group TM & Languages.

You can find the specification in the Resource Library/Articles, Presentation, Ebooks under the Parallel Section

If you have any comments, I invite you to post them here or in the Discussion forum.

TM Specification Drafting Group

To derprecate or not deprecate, that is the question.

Michael_Wong — Fri, 06 Nov 2009 19:41:32 GMT

Standards love to add things. They remove very little, but they do like to deprecate. This post will describe a collection of things that is heading that way, or not heading that way in C++ 0x.

In my posting on Intention to deprecate trigraphs in the next C++ Standard, we successfully demonstrated that much of the non-English speaking world will still need to rely on trigraphs as a way to get to UCN through "\" which may be inaccessible in some codepages. So we would object to deprecating it without an alternative.

In the last meeting in Santa Cruz, an alternative was proposed in Core issue 789:Replacing Trigraphs. In short, it does not so much deprecate trigraphs (which we like) as move trigraphs out of translation phase 1 so trigraphs are not recognized ahead of raw strings, but is still recognized ahead of other strings (as it is now). It seems that trigraph interaction with raw strings was always the real issue behind the original National Body comment. This interaction had become more prevalent because Raw strings are accepted as part of C++0x. This proposal will level the playing field to what it was again.

We reviewed the paper as a way of fixing the interaction of trigraphs and raw strings. We think the paper is ready to go, but we're holding it back because we're considering other approaches, including moving UCNs out of translation phase 1 or moving raw string recognition into phase 1.

We're still looking at deprecating exception specifications. Our current feeling is that we will deprecate them except for the ways of saying a function doesn't throw at all (e.g., the new noexcept feature, still being reviewed). This feature has been shown to be relatively useless since its inception.

We did a straw poll on deprecating or removing exported templates. I voted to support removal of export to reduce dialecting C++. However a straw poll in full committee seems to prefer deprecation. This feature has been implemented exactly by one company, and even their lead is not opposing its removal. We appreciate their selfless sense of the C++ community and appreciate their sacrifice in learning about why this feature was problematic. Sometimes, it does take doing to see the whole picture.

Finally, we deprecated the semantics of the register keyword. This keyword has been ignored by most compiler that I am aware of, so it is the right time to deprecate it.

As with all deprecation, have no fear. All compilers will generally continue to accept (and or ignore) these cases, so that your code will continue to compile.

The View (or trip report) from the Oct 2009 C++ Standard meeting Part 2

Michael_Wong — Fri, 06 Nov 2009 17:02:40 GMT

The Library side brought about some of the most interesting changes. I already discussed the key discussions with respect to unifying the Asynchronous futures proposal in The View (or trip report) from the Oct 2009 C++ Standard meeting.

This resulted in a paper which will be published in the upcoming mailing (in about a week from now), which will show the approach on Asynchronous Call A Simple Asynchronous Call.

The key changes there were:

A restoration of the variadic thread and async functions. This restoration is a consequence of analysis and request of the British Standards Institute.
A convergence on the "as if a new thread" in the launching of asynchronous work. This change avoids undefined behavior arising from any delay in destroying thread-local variables, but requires careful implementation to avoid excessive overhead.
Removal of the is_ready, has_exception, and has_value query functions. The presence of these function requires still other functions in the synchronous case. Evolution Working Group direction is that the complexity in interface is as yet unjustified, and prudence dictates a smaller initial interface.
Unspecified behavior for the use of timed wait functions when the unique_future was created from a deferred async.
The conversion from unique_future to shared_future will execute any deferred work.
The use of an enum class to better clarify the launching policy.

The other papers which support this is a resolution of most of the futures issues from National Body comments in Issues on Futures (Rev. 1) . A future describes components that a C++ program can use to retrieve in one thread the result (value or exception) from a function that has run in another thread.

These components are not restricted to multi-threaded programs but can be useful in single-threaded programs as well.

The other resolved issues include:

Supporting constexpr in the library properly fixing a number of issues: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/N2994.html.

Clarifying use cases of std::forward: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2951.html

A set of small bug fixes and minor improvements to forward_list. It addresses all the issues in raised in LWG Issue 897, and several other matters. It is in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2988.pdf

moves swap from the <algorithm> header to <utility> to address UK 300 because swap has become a common utility operation with several common idioms relying on it

resolving a collection of issues with atomics in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2992.html. Most of these issues are related to wording subtlties and wish for clarification from national body reviews.

we added new type traits is_trivially_copyable, is_literal_type, is_nothrow_constructible, is_constructible, is_explicitly_convertible, underlying_type in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/N2984.html

The adoption of N2554 (The Scoped Allocator Model) and N2525 (Allocator-specific Swap and Move Behavior) needed take account of the removal of Concepts from the Frankfurt meeting. It is in http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2982.pdf

Most of these are motivated by National Body comments from CD1. This shows the effort and focus of the committee during these periods as we continue to resolve the almost 600 comments that was received from the September 2008 CD1 draft.

There is now plan to issue a second draft for comment (post removal of Concepts, and with the fixes like above from CD1 comments). This will be CD2 and will be aimed for release after the next meeting in March 2010, in Pittsburgh hosted by Carnegie Mellon.

I will describe in another post more details on the schedule changes which is now clearer and I have updated in the C/C++ Standard hub

The View (or trip report) from the Oct 2009 C++ Standard meeting

Michael_Wong — Fri, 23 Oct 2009 21:42:00 GMT

Santa Cruz is a wonderful location for us to decide weighty matters such as how best to ship a C++ Standard with the overloaded number of issues. Normally a surfing town as I am told, I have not had a chance to even make it to the ocean shoreline as yet even though I am only mere blocks from it. So busy we are that let me waste no more time and recap.

1. P.J. Plauger (or Bill Plauger) has been the convener of the C++ meeting. There was an attempt to stop processing any new features in order to facilitate our promised shipping date for the Standard. The problem is what is new? Some issues are discovered late and are serious if not fixed. Some new issues are truly wish list and should be stopped. Other issues are somewhat in between but need to be weighted with all the other.

The vote that tried to stop all new feature failed probably because of how ambiguous the wording is, in my opinion. The issue isn't about stopping consideration of any new feature, but balancing all features based on their seriousness and only being able to handle a fixed number of them based on resource.

But the problem with that model of triage (which is often done in software industry), is that we are all volunteers and you just can't easily make volunteers do the hard thing, when they would rather do what they like.

The end result is that P.J. Plauger has tendered his resignation as convener. I and many would like to thank him for his service and his guidance which has enabled C++ meeting hostings well into 2011.

2. Both Evolution and Core Committees met in addition to Library. Evolution had to deal with a number of pending additions which had been long promised. The most significant discussion is the proposal to add Asynchronous and Futures to C++. This is a higher abstraction for concurrency that allows independent action with a return value.

This was controversial because there were two leading candidate proposals. The majority of the discussion allowed a unified proposal which offered:

A restoration of the variadic thread and async functions. This restoration is a consequence of analysis and request of the British Standards Institute.
A convergence on the "as if a new thread" in the launching of asynchronous work. This change avoids undefined behavior arising from any delay in destroying thread-local variables, but requires careful implementation to avoid excessive overhead.
Removal of the is_ready, has_exception, and has_value query functions. The presence of these function requires still other functions in the synchronous case. Evolution Working Group direction is that the complexity in interface is as yet unjustified, and prudence dictates a smaller initial interface.
Unspecified behavior for the use of timed wait functions when the unique_future was created from a deferred async.
The conversion from unique_future to shared_future will execute any deferred work.
The use of an enum class to better clarify the launching policy.

Interestingly, this discussion really only have bearing on two Library proposals which I will detail in a following blog post.

The formal motions for C++ Core language which resulted from this include the usual group of defect fixes, numbering into the 70 range. Basically, all Ready and Tentatively Ready issues of
n2962 except issues 799, 812, 861, 919, and 920.

There was also a paper called Reaching Scope of Lambda Expressions

n2998
Current lambdas restrict the referents of a lambda expression to the immediately-enclosing function or lambda expression. This restriction is severe and does damage to the utility of the lambda feature.

For example, a simple matrix multiplication kernal would require two enclosing scopes and there would be no captures. It is essentially equivalent to saying that the body of a nested loop cannot access function parameters.

Much of this is from the paper.

Consider the following function to multiply square matricies.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows();
    matrix c( n, n );
    for ( int i = 0; i < n; i++ ) {
        for ( int j = 0; j < n; j++ ) {
            double t = 0.0;
            for ( int k = 0; k < n; k++ ) {
                t += a[i][k] * b[k][j];
            }
            c[i][j] = t;
        }
    }
    return c;
}

Its rewrite into functions and lambdas, as intended by the adopted N2550, is as follows. Note that the rewrite is approximately the same size.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows();
    matrix c( n, n );
    for_range( 0, n-1, [&]( int i ){
        for_range( 0, n-1, [&]( int j ){
            double t = 0.0;
            for_range( 0, n-1, [&]( int k ){
                t += a[i][k] * b[k][j];
            } );
            c[i][j] = t;
        } );
    } );
    return c;
}

However this straightforward reformulation is ill-formed as per N2927 wording for 5.1.1 expr.prim.lambda paragraphs 9–12. To make the code well-formed, the function must be rewritten as follows, where inserted text shows new code, which sometimes alter variable references.

matrix operator*( const matrix& a, const matrix& b )
{
    int n = a.numrows( );
    matrix c( n, n );
    for_range( 0, n-1, [&]( int i ){
        const matrix& a1 = a;
        const matrix& b1 = b;
	int& n1 = n;
	matrix& c1 = c;
        for_range( 0, n1-1, [&]( int j ){
            const matrix& a2 = a1;
            const matrix& b2 = b1;
	    int& n2 = n1;
	    int& i2 = i;
            double t = 0.0;
            for_range( 0, n1-1, [&]( int k ){
                t += a2[i2][k] * b2[k][j];
            } );
            c1[i][j] = t;
        } );
    } );
    return c;
}

Such extensive mechanical editing will inhibit use, make errors more likely, and complicate code maintenance. Such editing is properly the domain of the compiler.

A third proposal n2989 "Unified Function Syntax" was not moved after significant discussion on whether it solved significant problem or not especially at this late stage, or just merely being a stylistic wish, especially if you have written large amounts of lambdas with the late specified return syntax and found current syntax ugly.

There was controversy because a previous proposal on auto lambda syntax was moved on the contingency that there would be room to explore a unified function syntax. However, as with all agreement in such a committee, the promise is always to allow the work to go forward with all the resource costs (such as authors and collaborators working together, review committee going over the proposal in this case over eight hours over several day), but there is no promise that it would be accepted. Such was the case, and of course the disappointment of the authors of this paper.

Well, in the next posting I will go over the Library proposal.

The View (or trip report) from the Oct 2009 C Standard meeting

Michael_Wong — Mon, 02 Nov 2009 06:17:33 GMT

This is the meeting that closes on all new features for the upcoming C1X Standard (with only a few minor known exceptions)

In this meeting, we processed a number of key issues. We incorporated a few additional details to the memory model and concurrency proposals taken from C++ Standardization. We moved zero-initialization for thread locals from 5.1.2p1 to integrate with 6.7.8p10

One proposal removed gets() from the standard. This has been a problematic function, and was made obsolete in TC3. The function gets() has been problematic because of uncertain newline removal. The answer for a long time is to use fgets() instead.

We reviewed whether C wishes to support a general syntax for attributes similar to C++. This was rejected as most members were uncomfortable with the need and the consequences. Instead, C will adapt keywords prefixed with a single underscore for future attributes. For example, the alignment proposal will use _Align.

Personally, I feel this will cause C more problems in the future as attributes proliferates. But I do not think it precludes future adaption of a generalized system, if the need becomes serious. although right now the consensus is that C does not want general system for attributes.

I also pitched the concept of a common vectorized type for C based on OpenCL. There was general enthusiasm for the feature as many felt the need to drive for future parallelization support based on many existing implementations of vector extensions. However, due to C1X being on a schedule for completion of features, and the relative size of this proposal, the members felt that this proposal need time to develop. Furthermore, there was interest in maintaining close liaison with OpenCL to ensure we do not create dialects of OpenCL if we were to pick subsets.

In the end, the meeting closed with great belief that we are on track to have a feature completed draft by the next meeting in April, 2010. This puts C on a very promising track to finish on time.

C Standard meeting in Santa Cruz Oct 26-30

Michael_Wong — Wed, 21 Oct 2009 21:54:54 GMT

Hi all, my name is Michael Wong. I will be attending the next C Standard meeting in Santa Cruz on Oct 26-30, representing IBM and Canada.

This promises to be a critical meeting as it is where the C Committee has nominated as the cutoff for adding features to the upcoming C1X (the code name for the next release of C).

One of the paper is the IBM comment on the Bounds Checking Library:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1388.pdf

where we have made responses as follows:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1389.pdf

IBM has also submitted one more proposal in addition to others.

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1408.pdf

This is a proposal to suggest work to start on a common vectorized type that will be native in C. Currently, the situation is like a jungle out there in that there is a proliferation of vector types from various platforms. Even within one compiler, there are many different vectorized type support because a compiler may need to support VMX, VSX, (Altivec), SSE2, MMX, OpenCL, to name a few.

This has caused a profusion of vectorized names which are similar but possibly not extendable as wider vector registers appear. It is also a recipe for non-portability of code.

The other part of the proposal uses OpenCL as a way to suggest one possible model (but not the only one) of how to support a common Vectorized type.

Please have a look and give me feedback if you wish.

And if you are in the Santa Cruz area, please join us, but first let me know so we can add you to the guest list as the meeting room space is limited based on the projected attendees.

Thanks and I will give a trip report post-meeting.

C++ Standard Meeting in Santa Cruz on Oct 19-24

Michael_Wong — Wed, 21 Oct 2009 16:45:27 GMT

I am attending the C++ Standard meeting in Santa Cruz. We have a number of issues of interest to us.

SCARY iterators is a way to improve portability invented by our IBM Watson Lab and collaborated on with testing using the xlC++ compiler. It also can give significant performance gains, especially in Blue Gene software:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2913.pdf

The other issue of interest is continuing discussion on resolution to the Trigraph deprecation issue. Although the idea of deprecation was rejected in Frankfurt, there was a desire to reach a common solution by replacing trigraph with something else. A paper was produced and we will review it in the next meeting:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2978.pdf

The solution will resolve many of the issues in my previous posts about trigraphs but we do have some comments. On the whole, we are pleased with this compromise approach.

The other issues that will be discussed will be how to control the proliferation of issues that could cause a prolonged delay of publication of the Standard.

Like any software delivery, shipping a Standard meets the same problems in that there will be many late issues come up out of integration and testing. Some of those will be new, while others are critical fixes. All issues need to be considered fairly through a triage process to see whether they are critical enough to require fixing before shipping, or can afford to be delayed until post-shipping.

This process as obvious as it is to do is not something that is easy to do at the Standard level where work is voluntary. There will be repercussion to this as we move forward if we do not adequately resolve this.

IBM's Alphaworks Software Transactional Memory Compiler

Michael_Wong — Thu, 06 Aug 2009 17:57:16 GMT

Transactional Memory (TM) is a high level abstraction for supporting a safe mutable shared state, such that the user does not have to worry about the low-level details of locking and sharing of global resources. It is basically a class of optimistic speculation techniques such that groups of memory operations are bundled as an atomic operation such that it can resolves the problems with locks, possibly support composability.

The basic idea is to move your group of atomic operations through, assuming that it will be successful, and only rollback when a conflict actually occurs.

At the moment, much of the ideas of TM are there as a way to test out the idea, and possibly be integrated into some future hybrid system. Even practitioners of TM knows there is a certain amount of hype that we have to deal with in any new technology before it drops to a trough and rebounds back to a realistic plateau.

A number of vendors have planned both hardware and software implementations of Transactional Memory.

The software transactional memory compilers from different vendors all use different syntax, and this creates a basic problem with interoperability, and common porting of code. I will deal with this in the next post.

IBM is also working in this area, and has released an Alphaworks compiler supporting Software Transaction, actually last year.

The IBM XL C/C++ for Transactional Memory for AIX is also accessible from the Resource Library of the C/C++ Cafe.

The public domain STM runtime is compatible with the AlphaWorks XLC STM release.
It was released through the Amino Concurrency Building Blocks project
The source code is here

I will have more to say about the Amino Building Blocks in a future post.

The View (or trip report) from the July 2009 C++ Standard meeting (Part 2)

Michael_Wong — Mon, 20 Jul 2009 07:55:13 GMT

One of the issue we were concerned about at this meeting was the intent to deprecate trigraphs. We wrote a paper indicating why we oppose this. This was reviewed in the Evolution Committee and many delegates accepted our position and need to support existing customers. This is good for existing trigraph users.

However, discussion in committee indicate that if we can find an alternate way to support these users then we should explore that with the blessing of the committee. I will be looking at alternatives in future postings.

The C++ Standard Library Working Group also ratified four proposals into the C++0x draft.

C++0x Stream Positioning

C/C++ I/O files predates modern file sizes, and are usually based on int or long. This proposal allows them to work better with the new long long type in C++0x.

Specifying the complexity of size() (Revision 1)

This paper addresses the issue of testing size() and not knowing their complexity constraint. This makes it difficult to use containers where testing size is a frequent operation.

Thread Unsafe Standard Functions

This paper does not make C++ Standard functions thread unsafe, despite the name. Its intention is to clearly identify functions adopted from the C standard that need explicit exemption from the general prohibition on data races.

For example, these are already exempt:
asctime, ctime, gmtime, localtime, strerror, strtok, rand,

The following functions may have previously been thread unsafe, but must be thread safe to enable effective programming. By failng to mention these functions, the standard implicitly requires them to be thread safe.

atexit, at_quick_exit, exit, fclose, free, quick_exit, malloc, signal

Furthermore, C++ locale objects are already adequate for thread-safe locales; setlocale() is thread-unsafe.

Fixing freestanding: iteration 2.2

A freestanding platform is one that has an Operating System. This proposal aims to:
· enable the intent of the freestanding specification compliance to be preserved, by adding only two headers to it relative to its C++98/C++03 contents, namely <initializer_list> and
<type_traits>
· maintain the historically low dependency of the C++ language, and of C++ compilers, on a corresponding library

The benefits of this proposal are:
· it enables current users of the freestanding specification to continue using that specification
· it enables compiler implementers to work fairly independently of library supply
· it enables library implementers to work fairly independently of compiler supply

The View (or trip report) from the July 2009 C++ Standard meeting

Michael_Wong — Fri, 17 Jul 2009 12:09:44 GMT

Hello all, we are here in Frankfurt as part of the Canadian delegation. This is a momentous meeting.

At this meeting, Concepts, the major feature of C++ 0x, which enables constrained genericity, or template argument prototyping, has been removed from the C++0x draft.

The reason this is big is because many people have worked on this for over 6 years, and it is probably one of the poster child feature for C++0x. Aside from this, Garbage Collection was also removed early in the process, because of fears of its complexity implications. These two features integrate pervasively into almost every area of the standard, are not orthogonal, and have many legacy impacts. The only other major feature that remain, because it has to is concurrency. This last one appears safe, at least.

The reasons for questioning Concepts at this point can be best described by a paper by Bjarne Stroustrup simply called "Simplifying the use of Concepts":

Simplifying the use of Concepts

Bjarne feels that this is a major setback and some feel that this could be patched. Our next chance could be about 5 years, because now it is a redesign, and it is questionable whether the usability, and implementation issues will really be solved.

In the mean time, there will be implications as we make a major change to the latest C++0x draft, likely issue it out for another Committee Draft and National Body Comment. Features that have been accepted since most of Concept entered in the September, 2008 San Francisco meeting may have to be reviewed as they get stripped of Concepts.

Enough about Concepts as I am sure this will not be the last we will hear of it. Lets move on to other things that we have accomplished in this meeting.

1. We plane to submit the Decimal Technical Report to ISO for Technical Report Ballot. This is an important process goal because it enables a specification for using base-10 as the basis for computations, instead of base-2 as we have been using, and continue to use.

Decimal Technical Report

2. For Core language changes, we accepted a number of new papers. The links do not work until the papers are posted about 2 weeks from now.

New wording for C++0x Lambdas (rev. 2)

This paper rewords all of the lambda sections which originally had inadequate wording and examples.

Implicitly-Deleted Special Member Functions.

Now that we have removed concepts, some good things that were brought in by concepts should not be thrown out with the bathwater. This intent of this feature is to ensure that template argument deduction fails when it finds an implicitly-declared special
member function whose definition would fail to compile. The problem came up in the context of concepts, where the
type std::pair<const int, int> was getting an implicitly-declared copy-assignment operator, such that it met the
requirements of the CopyAssignable concept. However, the definition of the copy-assignment operator is ill-formed
(due to the const member), causing unexpected failures. By making this copy-assignment operator deleted, it can no
longer be used to satisfy the requirements of the CopyAssignable concept. Even without concepts, this issue still
comes up with the extended SFINAE rules.

Range-Based For Loop Wording (Without Concepts)

This is another one of those feature that has to be readjusted because of the loss of Concepts. Specifically, range-based for statements will be using argument-dependent lookup of begin and end (which always includes those begin and end functions in namespace std) to provide the iterator to the beginning and ending of the sequence. Specify range-based for statements so that arrays and initializer lists have no dependencies on <iterator>. Refactor <initializer_list> so that it as no dependencies on other headers and includes no other headers.
Specify the library headers that are to #include <initializer_list>.

Pack expansion and attributes (rev. 2)

The aligned_union template in the library was intended to provide simple support for union-like types whose elements may support non-trivial constructors and destructors. When this support was added directly into the language the library template was deemed superfluous, and removed. (This was a TR1 extension, so there are no back-compatibility issues).

However, it has emerged that there remains at least one use case for the feature. When trying to create a 'discriminated union' template using variadic templates, it is not possible to to declare the members of the union via a pack-expansion. This requires a fall-back on an aligned_union like utility.

This would be significantly easier to write if the [align] attribute supported a pack-expansion to return the strictest alignment. This feature is already supported if the types are listed individually, but the grammar does not yet support pack expansion within an attribute. This is seen as the motivating example to extend the attribute grammar to support pack expansion, where the named attribute explicitly documents support.

Explicit Virtual Overrides

We would like to tighten the rules for overriding virtual functions, to detect these problems:

* a base class B has a virtual function f, and the user declares their own f in derived class D, thereby accidentally overriding B::f.
* a base class B has a virtual function f, and the user wishes to override that function in the derived class D, but misspells the name as D::foo.
* a base class B has a virtual function f, and the user wishes to override that function in the derived class D, but inadvertently alters the parameter list.

We are deliberately not solving the problem that a base class B1 has a virtual function f, another base class B2 also has a virtual function f with the same signature, the user derives a class D from both B1 and B2 and declares D::f to override both B1::f and B2::f, one of which may have been inadvertent. (This is sometimes referred to as the Siamese Twins problem.)

The scope of the problem was reduced to the minimal necessary to solve the common real-world problems. This means it does not tackle ideas such as 'final overriders' or function renaming, both of which would be available if a scheme closer to the C++/CLI standard was pursued.

There are also library papers which have been approved. I will describe that in the next posting.