- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just read an article about a proposal that is shaping up to define new classes that would support threading as part of the C++ language (http://www.techweb.com/wire/software/163700651). Robert Buhr (U. of Waterloo) has developed micro-C++ to foster the developement of a larger set of threaded applications to take advantage of the upcoming multi-core processors.
Should these classes be adopted as part of the C++ language specification? I can think of three levels of threading:
- OpenMP - simple pragmas that are translated into threaded code by the compiler (current micro-C++ would also fit here).
- Explicit threading API (Pthreads, Win32 threads).
- Part of language specification (if micro-C++ were made part of C++ spec).
So, what is the right "level" for threading to be accessible by programmers? What about ease of learning, ease of use, applicability, and robustness? Are there advantages that one level would have over the others? Is portability of a model across languages important any more?
--clay
- Tags:
- Parallel Computing
Link Copied
1 Reply
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ongoing discussion of the C++ language support for threading is
here
Some prior stuff in n1680.pdf and n1777.pdf.
There's some work on adding a threads class to the standard library.
The problem with the memory model work is they're defining it in terms of a meta-implementation much like they did with Java. Some of the same principals are involved. It could be problematic as it is likely to be rather narrowly defined. If, hypothetically speaking, someone came out with transactional memory, they may find it doesn't fully fit with the C++ memory model and won't be able to fully exploit it.
Also, they're ignoring things like better language support for pointer abstraction. The usage of smart pointers for things like lock-free programming, which is a really effective way of exploiting multi-core concurrency, was probably the main instigation for looking at multi-threading support in C++ in the first place. The attitude towards threading before that was rather antipathic.
--
Joe Seigh
here
Some prior stuff in n1680.pdf and n1777.pdf.
There's some work on adding a threads class to the standard library.
The problem with the memory model work is they're defining it in terms of a meta-implementation much like they did with Java. Some of the same principals are involved. It could be problematic as it is likely to be rather narrowly defined. If, hypothetically speaking, someone came out with transactional memory, they may find it doesn't fully fit with the C++ memory model and won't be able to fully exploit it.
Also, they're ignoring things like better language support for pointer abstraction. The usage of smart pointers for things like lock-free programming, which is a really effective way of exploiting multi-core concurrency, was probably the main instigation for looking at multi-threading support in C++ in the first place. The attitude towards threading before that was rather antipathic.
--
Joe Seigh
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page