[gliese1337]

Do you feel the same way about, say, garbage collection? The point of high-level languages is to eliminate the need to know about the underlying platform. Automatically dealing with the details of parallelism is not different from automatically dealing with the details of memory management.

Of course, there are some things that are going to always be application-specific (not platform specific), and you should be able to get around the abstraction to fiddle with those. And one of the strong selling points of C and C++ is that they do expose the underlying platform so you can do "bare-metal" programming and platform-specific tricks. But if you need to do that, just don't using this part of the standard library! Adding more, better abstractions does not hurt anybody who doesn't want to use them, and helps everybody who does.

[SamReidHughes]

> Do you feel the same way about, say, garbage collection?

What.

Obviously garbage collection would be even worse than the introduction of threading concepts into C++.

Since you seem to think it's a reasonable thing to compare against, it's clear you have no clue of the perspective Blunt is taking into this.

[gliese1337]

> Obviously garbage collection would be even worse than the introduction of threading concepts into C++.

Unavoidable, all-the-time, no-manual-option-available garbage collection would be a terrible idea, because that goes against the point of C++ as a high-level language that still allows low-level access. Similarly, introducing fully automatic, unavoidable parallelism implemented One True Way a la Fortress into C++ would be a bad idea.

But nobody complains about the fact that C++ gives you the option to use auto pointers, or that it will call destructors on object members for you so you don't have to think about the internals when you delete a complex object. It's nice to have the option to let the language do a lot of stuff for you in a standard way so that you don't have to think about it.

I don't see how this is any different. It would be nice to have a standard implementation that makes a lot of parallelism decisions for you, so that you don't have to think about it in situations where it's not really relevant. Having that available will not prevent you from rolling your own and making your own implementation decisions appropriate to the circumstances when it is relevant. So how can that possibly be a bad thing, any more than C++'s memory management facilities are?

[SamReidHughes]

Garbage collection is completely different from these concurrency tools because these concurrency tools can be avoided by you while used by a library that you use, without you having to care. Garbage collection is like exceptions in that if a library expects garbage collection, you can't use it if you're not using that feature. Now you have to worry about the details of the library you use. That's why garbage collection is worse.

Also it's much more contrary to the spirit of the language. People already use threading libraries all the time, so having a standard one is not altogether absurd. The same is not the case with garbage collection.

The fact that you don't understand this, that you thought it was convincing to begin your post with "Do you feel the same way about, say, garbage collection?" makes it clear you don't have the C++ worldview to talk with Blunt about this issue.

[sausagefeet]

The reason languages want threading as part of the language is for the memory model. The Boehm paper covers this in-depth. Libraries also need to be thread-aware to some degree, for example reentrant functions and thread-local storage issues.