This is interesting. So far, we have used threads either from C libraries (Win32 threads, pthreads) or from some C++ libraries built on top of the C ones (Boost Threads, ACE). Now, the proposal is not only to add a threads library to the Standard, but also to make C++ compilers thread-aware.
But what happens on systems where threads simply don't exist?
What I mean is: now it is possible to make fully Standard compliant compiler (and libraries) even for platforms that don't support threading. After a threads library is added, is it going to be possible?
Nemanja Trifunovic wrote: now it is possible to make fully Standard compliant compiler (and libraries) even for platforms that don't support threading.
Yes. It's possible to implement a user-mode threading library - that's all that the pthread library is for Unix/Linux. The threading is supported fully within the user process; the OS doesn't even know (or care) they exist.
"Punctuality is only a virtue for those who aren't smart enough to think of good excuses for being late"John Nichol "Point Of Impact"
Maybe I'm not understanding everything, but what's the gain for moving thread processing out of the OS domain, and bring it into the language specification of C++?
I've been using CreateThread() with its associated set of API's and it's been working fine that way. What's to be gained by having a C++ 'pthread' when using CreateThread() returns a pointer to the newly created thread anyway.
CreateThread (or better, __beginthreadex) and pthreads are the "C" way of doing things, and as many other C constructs they are not particulary safe and easy to use. Have you tried Boost threads for instance? That's the C++ way of dealing with threads.