Updated 15Aug11
Intro
The scope of this post is to learn how the renewed C and C++ standards may help programmers of concurrent systems do their job. I will of course look at this through my CSP-type glasses, with years of occam programming and using CSP/channel-type libraries in ANSI C in embedded systems as my bias. (Post 021- The problems with threads takes me up to this point.)
Letters-in-words and words that I will use to search in the documents. This should(?) indirectly direct me to all the new keywords:
My post 021 starts with quoting "It is widely acknowledged that concurrent programming is difficult" (Lee). Future programmers of C and C++ may learn by expensive experience that it is even "very difficult".
These papers start after the climax in the middle of Lee's paper. Where he goes on in the right direction, these papers don't go back to square one. They elevate.
Ok, they add concurrency where there was none before. That is their motivation, and it is an important motivation. But whose idea was it to build this on C and C++? Did they ask?
These people are specialists. The papers are not for amateurs, like I would be in their eyes. I have been hidden from most of the problems they solve during my 30 years of concurrent programming. Starting off with a runtime system in 1980 that we bought from a university person who said his code in PL/M had "no errors". We though he was more crazy than he was! Modula 2 and a runtime system for it. Occam on transputers and occam to C (SPoC). Occam will stay the programmer's love of my life. And then back a few hops to C and CSP-type runtime systems.
I really don't understand which planet the open-std.org is on when it comes to concurrency. In post 021 Per Brinch Hansen is quoted for "that Java ignores the last twenty-five years of research in parallel programming languages.". How many years will future C and C++ programmers have lost?
I am not able to see the answer to any of the questions above. There may be answers, but they seem hidden for me. Except: yes - C is a subset of C++ still, at least when it comes to the memory model. I think.
A language isn't for the future just because "futures" are implemented. This is a pattern that I could easily code in occam and install some 20 years ago. But it's nice to have it in a language. And it is nice to have atomicity described. Etc.
But it is the complexity explosion of the standard that worries me. Inspired by Lee, they are two vast seas of nondeterminism - used in another domain - the definition-of-standard domain.
This probably is very reasonable (from C++ page 1152):
But this is rather ok (C++ page 11):
But isn't that what open-std.org has set out to do for me? Make it possible to build any concurrency paradigm on top of what they now give me? Probably they haven't missed that goal. Stroustrup told me exactly this when I approached him at Simula 67's 25th anniversary in Oslo in 1992: C++ does not have any concurrency to let anybody build their own. Now they are building their own.
Last comments
Adam Sampson's thesis Process-Oriented Patterns for Concurrent Software Engineering that he posted in a comment to post 021 certainly points to another direction of research - and present good practices. And I must repeat: the Go programming language faq also referenced in post 021.
Postscript
Is the world really crying for these two houses built on sand?
What did you say, do you need a C/C++ concurrency expert? If you find a good one, you'd need to wait 5-10 years before you know whether he was as good. And he wouldn't know if the house burnt. Working for other companies, making more good money.
.
.
Intro
The scope of this post is to learn how the renewed C and C++ standards may help programmers of concurrent systems do their job. I will of course look at this through my CSP-type glasses, with years of occam programming and using CSP/channel-type libraries in ANSI C in embedded systems as my bias. (Post 021- The problems with threads takes me up to this point.)
- I assume that C1X should end of with C12 for the year's publication data ("formal adoption of a revised standard by the end of 2011, with a publication date of 2012" (C - The C1X Charter)).
- And C++0x I assume means that they are late, but from the wiki-page is looks like it's going to end up with C++11. As of 12 August 2011, the C++0x specification has been approved by the ISO. The final working draft before final ISO approval standard is N3291, dated 5 April 2011. This draft is not publicly available; the most recent working draft available is (N3242) dated 28 February 2011. So, it's probably going to be called C++11.
- C1X
http://en.wikipedia.org/wiki/C1X
N1548 - 2 December 2010 - C++0x
http://en.wikipedia.org/wiki/C++0x
N3242 - 28 February 2011 (last before approved) - ISO C++ Strategic Plan for Multithreading
N1815 - 2005
Letters-in-words and words that I will use to search in the documents. This should(?) indirectly direct me to all the new keywords:
- "thread"
- "multi" (task thread -threading)
- "concurren" (t cy tly)
- "synchron" (ization, ous, asynchron..)
- "communicat" (e ion ing)
- "atomic"
- " race" (to exclude brace..)
- "deadlock"
- "process" (no such term, but there are some threads by name "process")
- "schedul" (e, ing)
- "happens before"
- "inter-thread happens before"
- Process (no: thread) model (versus or and object model)?
- Synchronization model?
- Communication model?
- Memory model - why is there so much about this?
- Will the C concurrency features be a subset of the C++ concurrency features?
- The difference between third-party thread by library (as discussed in post 021) and language defined thread by library as defined here. Is it assumed that the compiler knows what a process (or whatever) is? The answer to this is a function of what I would see from the above list
- Per definition it will it be A Good Thing to build a CSP library on top of these! How "nice" will such a library be, i.e. how easy to get correct? (Again, see post 021)
My post 021 starts with quoting "It is widely acknowledged that concurrent programming is difficult" (Lee). Future programmers of C and C++ may learn by expensive experience that it is even "very difficult".
These papers start after the climax in the middle of Lee's paper. Where he goes on in the right direction, these papers don't go back to square one. They elevate.
Ok, they add concurrency where there was none before. That is their motivation, and it is an important motivation. But whose idea was it to build this on C and C++? Did they ask?
These people are specialists. The papers are not for amateurs, like I would be in their eyes. I have been hidden from most of the problems they solve during my 30 years of concurrent programming. Starting off with a runtime system in 1980 that we bought from a university person who said his code in PL/M had "no errors". We though he was more crazy than he was! Modula 2 and a runtime system for it. Occam on transputers and occam to C (SPoC). Occam will stay the programmer's love of my life. And then back a few hops to C and CSP-type runtime systems.
I really don't understand which planet the open-std.org is on when it comes to concurrency. In post 021 Per Brinch Hansen is quoted for "that Java ignores the last twenty-five years of research in parallel programming languages.". How many years will future C and C++ programmers have lost?
I am not able to see the answer to any of the questions above. There may be answers, but they seem hidden for me. Except: yes - C is a subset of C++ still, at least when it comes to the memory model. I think.
A language isn't for the future just because "futures" are implemented. This is a pattern that I could easily code in occam and install some 20 years ago. But it's nice to have it in a language. And it is nice to have atomicity described. Etc.
But it is the complexity explosion of the standard that worries me. Inspired by Lee, they are two vast seas of nondeterminism - used in another domain - the definition-of-standard domain.
This probably is very reasonable (from C++ page 1152):
29.6.5 Requirements for operations on atomic types [atomics.types.operations.req]
6 #define ATOMIC_VAR_INIT(value) see below
Remarks: The macro expands to a token sequence suitable for constant initialization an atomic variable of static storage duration of a type that is initialization-compatible with value. [ Note: This operation may need to initialize locks. — end note ] Concurrent access to the variable being initialized, even via an atomic operation, constitutes a data race.[ Example: atomicPlease help me. And if I am able to understand, then I need help with some more.v = ATOMIC_VAR_INIT(5); — end example ]
But this is rather ok (C++ page 11):
1.10 Multi-threaded executions and data races [intro.multithread]
1 Every thread in a program can potentially access every object and function in a program (10)
(10) An object with automatic or thread storage duration (3.7) is associated with one specific thread, and can be accessed by a different thread only indirectly through a pointer or reference (3.9.2).Let's say that I want to implement a CSP library, and when the second process is on a channel, I want to do the rendezvous memcpy from inside the sender process to inside the receiver process. So now I know that I may code this. In C or C++. But observe the level. It's underneath where I should be.
But isn't that what open-std.org has set out to do for me? Make it possible to build any concurrency paradigm on top of what they now give me? Probably they haven't missed that goal. Stroustrup told me exactly this when I approached him at Simula 67's 25th anniversary in Oslo in 1992: C++ does not have any concurrency to let anybody build their own. Now they are building their own.
Last comments
Adam Sampson's thesis Process-Oriented Patterns for Concurrent Software Engineering that he posted in a comment to post 021 certainly points to another direction of research - and present good practices. And I must repeat: the Go programming language faq also referenced in post 021.
Postscript
Is the world really crying for these two houses built on sand?
What did you say, do you need a C/C++ concurrency expert? If you find a good one, you'd need to wait 5-10 years before you know whether he was as good. And he wouldn't know if the house burnt. Working for other companies, making more good money.
.
.
