views:

747

answers:

7

Obviously we will still maintain it, but how useful will it be, once the C++ standard guarantees is.

What about synchronization primitives (Mutex, conditional variables) with advent of the new standard?

Do you consider pthread harder to master as opposed to std::thread?

+15  A: 

C isn't going away. POSIX isn't going away. Multithreaded code written in C for POSIX isn't going away. So pthreads isn't going away.

Many implementations of std::thread will use pthreads under the hood.

"The Pthreads API is defined in the ANSI/IEEE POSIX 1003.1 - 1995 standard." -- POSIX Threads Programming https://computing.llnl.gov/tutorials/pthreads/

Marsh Ray
well it will be easier to develop cross-platform using the standard vs. using platform specific library...
vehomzzz
People will still program in C, and C++0x won't help them.
nos
I am NOT talking about C... I am talking about C++
vehomzzz
@enigma: C++ is usually built ontop of C libraries (it is rarly usefull to creat things from scratch). Thus any std::thread implementatin will be a wrapper ontop of a C library (potentially pthreads).
Martin York
Well, `fstream` didn't make `open/create/read/write` POSIX calls obsolete even in C++, for example - how is this different?
Pavel Minaev
A: 

Regardless of technical comparisons, it took the best part of a decade to get even reasonably decent C++ 98 support from all major platforms/vendors. This alone ensures pthreads will be going strong in 2020.

Adam Wright
Most of the work for implementing the threads library has already been done by boost - and they have a TR1 emulation library already for compilers with incomplete support. It won't be long until support for library features is available on all major compilers, alebit possibly requiring an external library like that.
bdonlan
G++ is already implementing the threads library, in fact: http://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a00568.html
bdonlan
Having support in Boost won't help, for example, Microsoft in adding support to their compiler. Even though they could, I don't see them using the boost code. I foresee a period of maybe 5 years until all compilers have (mostly) complete C++0x thread support, including getting the semantics right for all of the corner cases. This may include corrections to the standard as well, where things were not fully specified and noone has noticed yet.
KeithB
+8  A: 

C++ implementations on platforms that support pthreads will probably implement the language features in terms of pthreads - so no, it isn't going to be obsolete.

anon
+5  A: 

POSIX is an operating system standard. C++0X is a language standard. Having threads in the second will not obsolete the first. There is a collaboration between the two so that the second is implementable on the first. (And there is also work in process to have a C++ interface for POSIX).

AProgrammer
A: 

Maybe for new code, using what is in the standard will be the right way to go. We will have to wait and see how solid the implementations in the major compilers are. But there won't be much benefit to converting existing code from pthreads, assuming it is working now. This includes new code written in a shop that already have a lot of experience with pthreads.

KeithB
+2  A: 

std::thread does not include support for priorities, controlling the size of the thread stack, controlling the scheduling policy, or controlling the processor affinity.

Scheduling class and priorities are crucial for real-time systems. Processor affinity and stack size are really important for high-performance systems. Such applications will either continue to use the native thread facilities, maybe in addition to std::thread, maybe instead of std::thread, maybe through vendor extensions that expose the needed features along with std::thread.

coryan
A: 

At least correct for boost thread:

  • It does not support stack size parameter
  • It does not support setpshared attribute

So no... There is some things to do before OS API could be considered obsolete. (and BTW threads are implemented over pthreads)

Artyom