The Future of C++ Concurrency and Parallelism(bartoszmilewski.com)
bartoszmilewski.com
The Future of C++ Concurrency and Parallelism
http://bartoszmilewski.com/2012/05/11/the-future-of-c-concurrency-and-parallelism/
1 comments
I'm against this. They are trying to impose rules (threading concepts) into the C++ language where it ought not to be. Threads are platform specific (ARM, Intel) albeit with the same idea but underpinnings are different. They are arguing about thread local variables and concurrency issues in the context of the C++ language or standard libraries when really these things are dependent upon the application being written. We don't need all this garbage in the language and there are plenty of class libraries out there to deal with common hardware platforms already that do quite well. Trying to drive a design pattern from high atop ivory towers is stupid and you would think these people would have learned this by now.
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.
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.
> 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.
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.
> 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?
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?
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.
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.
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.
Read Hans Boehm's paper "Threads Cannot be Implemented as a Libray": http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf
It would have been nice if instead of presumptuously demanding the parent read a long article (assuming without evidence that he knows nothing about such issues) you had briefly explained why the existing state of affairs with respect to C++ concurrency is inadequate and why these features are actually helpful.
That is why God invented abstracts...
I don't see the problem with defining a standard API for some common problems. This doesn't pollute the language, simply makes portability better - if you need it.