"The Concur Project: Some Experimental Concurrency Abstractions for Imperative Languages"

http://video.google.co.uk/videoplay?docid=7625918717318948700&q=Herb+Sutter

zz

zz wrote:
> 
> "The Concur Project: Some Experimental Concurrency Abstractions for Imperative Languages"
> 
> http://video.google.co.uk/videoplay?docid=7625918717318948700&q=Herb+Sutter

Just skimmed through this one, it's about the same as some others you can find on his website.

This concurrency stuff is very interesting. But I've decided I won't talk about it before Jan 1, 2007.

:-)

An elegant solution for concurrency is probably the most challenging problem facing modern programming languages. It may take a year or so, but I am confident that D will rise to the occasion here.  DMD will probably have a decent solution implemented far before any C++ compiler.

-Craig

Craig Black wrote:
> An elegant solution for concurrency is probably the most challenging problem facing modern programming languages. It may take a year or so, but I am confident that D will rise to the occasion here.  DMD will probably have a decent solution implemented far before any C++ compiler.
> 
> -Craig 
> 

Perhaps D can then adopt Herb Sutter's slogan as a motto: re-enabling the free lunch...

Craig Black wrote:
> An elegant solution for concurrency is probably the most challenging problem facing modern programming languages. It may take a year or so, but I am confident that D will rise to the occasion here.  DMD will probably have a decent solution implemented far before any C++ compiler.

The C++ committee is hard at work on improving threading support in C++. I figure I'll let them do the dirty work, and then we'll cherry pick the best! Especially since I have a hard time understanding it, and we have enough on our plate in the meantime.

Walter Bright wrote:
> Craig Black wrote:
>> An elegant solution for concurrency is probably the most challenging problem facing modern programming languages. It may take a year or so, but I am confident that D will rise to the occasion here.  DMD will probably have a decent solution implemented far before any C++ compiler.
> 
> The C++ committee is hard at work on improving threading support in C++. I figure I'll let them do the dirty work, and then we'll cherry pick the best! Especially since I have a hard time understanding it, and we have enough on our plate in the meantime.

I've been keeping an eye on the discussion since... well, since it was the subject of speculation and ridicule on c.p.t :-p  But there are a lot of very capable people involved and it has started coming together quite nicely.  The really interesting bit in my opinion is that they're talking about tossing the idea of sequence points and replacing it with something more compatible with concurrency.  And it seems some of the roots of the discussion were on comp.std.c++ where a compiler writer (can't remember who offhand) pointed out that the C++ concept of sequence points had no relation to how a compiler actually compiles and optimizes code, so strengthening the guarantees in the sequence point model was not feasible.  In fact, one thing has struck me over the course of the committee discussions: some of the most difficult problems they've been grappling with (like those above) could be solved quite neatly by D's concept of 'volatile'.  I think this is one very interesting aspect of a programming language that was designed by a compiler writer (you) versus a committee that, by and large, has little understanding of the real issues involved in some of their decisions. That said, I do think D's volatile may be a bit too low-level for the average programmer, so a carefully designed memory model may turn out to be quite useful anyway.  But then it may also hobble compilers to such a degree that the opportunities for a lot of useful optimizations are lost, or that optimization becomes far more complicated.  I'm very interested to see how things turn out :-)

As for the library aspect, I think the D community already has some projects which are quite competitive with what is planned for C++.  And some of the more advanced bits, like futures, will probably make it into D before too long as well.  Finally, that D is a garbage collected language without object copy semantics makes some things possible or even trivial for concurrency in D that are just not so in C++.  Not to mention delegates and some of the other advanced features that are not even planned for the next iteration of C++.  So I am confident that D will be quite competitive with whatever comes out of C++ 0x concurrency on a library level, and we'll likely have it years before it gains traction in the C++ community.  But again, what truly interests me are the language changes anyway.


Sean

"Walter Bright" <newshound@digitalmars.com> wrote in message news:ekip5v$1igk$2@digitaldaemon.com...
> Craig Black wrote:
>> An elegant solution for concurrency is probably the most challenging problem facing modern programming languages. It may take a year or so, but I am confident that D will rise to the occasion here.  DMD will probably have a decent solution implemented far before any C++ compiler.
>
> The C++ committee is hard at work on improving threading support in C++. I figure I'll let them do the dirty work, and then we'll cherry pick the best! Especially since I have a hard time understanding it, and we have enough on our plate in the meantime.

Good approach.  No need to do it yourself if they are going to solve it for you.  I have a hard time with concurrency too.  I think that it's something that you have to do for a while to really grasp well.

-Craig

Sean Kelly wrote:
> In fact, one thing has struck me over the
> course of the committee discussions: some of the most difficult problems they've been grappling with (like those above) could be solved quite neatly by D's concept of 'volatile'.

Wouldn't that be ironic? D's volatile is an inspiration that just came to me out of ignorance as I was listening to Scott Meyer's double checked locking presentation on the perils of code motion. I thought, maybe all that needs to happen is to be able to draw a horizontal line and disallow code motion across that line. If I knew more about threading, I probably would have never thought of it.

It's amazing how one's thoughts are constrained by the rut of one's experience.

> As for the library aspect, I think the D community already has some projects which are quite competitive with what is planned for C++.  And some of the more advanced bits, like futures, will probably make it into D before too long as well.  Finally, that D is a garbage collected language without object copy semantics makes some things possible or even trivial for concurrency in D that are just not so in C++.  Not to mention delegates and some of the other advanced features that are not even planned for the next iteration of C++.  So I am confident that D will be quite competitive with whatever comes out of C++ 0x concurrency on a library level, and we'll likely have it years before it gains traction in the C++ community.  But again, what truly interests me are the language changes anyway.

I agree. D is way ahead even of paper *proposals* for C++, let alone implemented features available to programmers. With tuples D seems to have passed a turning point. Andrei always told me that tuples were a very big deal, but it's a little shocking how much of a dramatic improvement they offer.