4 ms·

The new C++ standard has std::thread (came from boost::thread) and most compilers already support it. So threads in C++ are no longer provided by a library, rig

by 16s 15y ago

The new C++ standard has std::thread (came from boost::thread) and most compilers already support it. So threads in C++ are no longer provided by a library, right? Am I missing something, is std::thread not good enough? Edit: I meant to write, "provided by an external library".

scott_s 15y ago
std::thread is a library - in fact, all of std:: are libraries. The new C++ standard has an actual memory model and a thread interface but that's not the same as parallelism being integrated into the language. Hans Boehm's paper, Threads Should Cannot be Implemented as a Library: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.2412&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...., brought this up a while back. The new memory model in C++ (http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/) helps solve the problems he brought up in that paper. The new C++ standard now has a memory model, and (if I understand the implications correctly), there is well-defined behavior when using threads in C++. But the author's point is deeper. Providing an interface to threads, and a well-defined memory model, is a good step. But threads are a primitive for implementing parallelism. They are a very thin abstraction. The author of this article is arguing for richer abstractions that are integrated into the language. If you want to write parallel programs, and you have to use threads, mutexes and condition variables to do it, your code is going to be harder to write, debug and reason about than if you had used higher level abstractions. (And you will probably end up reimplementing some parts of those higher level abstractions.) In this regard, C++ is behind. So, kudos to the Cilk team for integrating their work into g++.
- 16s 15y ago
  Yes, you are right std::thread is a library. I meant to write "provided by an external library". But I won't edit my original comment as doing so would take-away from your response. I see std::thread as a great first step. The richer abstractions will come later, but I think discounting std::thread is unwise. It's a great advance for C++.
  - scott_s 15y ago
    Libraries are the same no matter what namespace they live in [1]. The C++ compiler does not give special treatment to the libraries in std::. So there's no different between "external" libraries and libraries specified by the standard. [1] I suspect that most of the compilers will make the std::atomic_* interface (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n242...) compile down to compiler intrinsics, but the interface will still be just a template library.
- amanda1314 15y ago
  When you have Herpes, HIV/AIDS, hpv,or any other STD, it can feel like you are all alone in the world DatingHerpesSingles.com is a place where you didn't have to worry about being rejected Just feel free to chat, share stories, make friends in your local area.
snorkel 15y ago
The article suggests that the programmer should not have to explicitly manage threads but instead expand the semantics of the language the language so that the programmer can express which tasks and data can be handled in parallel, then let the compiler/hardware decide how to do it.
- protomyth 15y ago
  It seems like C/C++ are the wrong languages to implement this type of automatic parallelism. It seem like these features would make so common uses for C/C++ problematic (embedded & games). // maybe Occam can make a comeback

by 16s 15y ago

scott_s 15y ago

std::thread is a library - in fact, all of std:: are libraries. The new C++ standard has an actual memory model and a thread interface but that's not the same as parallelism being integrated into the language. Hans Boehm's paper, Threads Should Cannot be Implemented as a Library: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90.2412&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.90...., brought this up a while back. The new memory model in C++ (http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/ http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/) helps solve the problems he brought up in that paper. The new C++ standard now has a memory model, and (if I understand the implications correctly), there is well-defined behavior when using threads in C++. But the author's point is deeper. Providing an interface to threads, and a well-defined memory model, is a good step. But threads are a primitive for implementing parallelism. They are a very thin abstraction. The author of this article is arguing for richer abstractions that are integrated into the language. If you want to write parallel programs, and you have to use threads, mutexes and condition variables to do it, your code is going to be harder to write, debug and reason about than if you had used higher level abstractions. (And you will probably end up reimplementing some parts of those higher level abstractions.) In this regard, C++ is behind. So, kudos to the Cilk team for integrating their work into g++.

16s 15y ago
Yes, you are right std::thread is a library. I meant to write "provided by an external library". But I won't edit my original comment as doing so would take-away from your response. I see std::thread as a great first step. The richer abstractions will come later, but I think discounting std::thread is unwise. It's a great advance for C++.
- scott_s 15y ago
  Libraries are the same no matter what namespace they live in [1]. The C++ compiler does not give special treatment to the libraries in std::. So there's no different between "external" libraries and libraries specified by the standard. [1] I suspect that most of the compilers will make the std::atomic_* interface (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2427.html http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n242...) compile down to compiler intrinsics, but the interface will still be just a template library.
amanda1314 15y ago
When you have Herpes, HIV/AIDS, hpv,or any other STD, it can feel like you are all alone in the world DatingHerpesSingles.com is a place where you didn't have to worry about being rejected Just feel free to chat, share stories, make friends in your local area.

snorkel 15y ago

The article suggests that the programmer should not have to explicitly manage threads but instead expand the semantics of the language the language so that the programmer can express which tasks and data can be handled in parallel, then let the compiler/hardware decide how to do it.

protomyth 15y ago
It seems like C/C++ are the wrong languages to implement this type of automatic parallelism. It seem like these features would make so common uses for C/C++ problematic (embedded & games). // maybe Occam can make a comeback