I'm working on a project that makes heavy use of multithreading; I think it's been years since I wrote code that didn't at least use std::thread or std::async to some extent.
I started programming in C for bare-metal AVR microcontrollers (no threading needed in that case), and I didn't really move into C++ until just after C++11 was already established; that is to say, I have always had access to concurrency tools that are built into the standard library.
I'm curious how threads were implemented prior to C++11; I know that 3rd-party libraries exist for this, but how did the libraries themselves handle it? I'm assuming the only option was to use calls to the OS with a lot of preprocessor macros depending on the target OS. Writing loops with a stored state would work, but not only did coroutines not exist in the STL until much later, but this wouldn't take advantage of multi-core CPUs, which were already commonplace before C++11.
There are certainly some times I take modern language features for granted. So, for the experienced programmers out there: How did it used to be done?
6 Comments
auv_guy@programming.dev · 6 pts · 3y
On POSIX systems there is the pthread library. Pretty easy to use. At least on Linux I think std::thread is just a wrapper for pthread.
o11c@programming.dev · 4 pts · 3y
C++11 just standardized
boost::thread, which has been a thing since ... at least 2001. Which was the same year POSIX standardized threads. Boost itself dates back to 1998, the same year C++ standardized.Documentation prior to Boost 1.31 is hard to find.
corroded@lemmy.world · 1 pts · 3y
I should have expected that STL threads came from boost. I feel like the committee sometimes makes questionable decisions regarding what parts of Boost to standardize (I have yet to find a legitimate use case for std::any), but threads were a good decision.
rmam@programming.dev · 3 pts · 3y
corroded@lemmy.world · 1 pts · 3y
I code almost exclusively for Windows these days, and I dread the times I have to interface with the Win32 API directly. The worst part IMO are the macro definitions that reference another macro definition that reference multiple layers of pointers. I would imagine that the first order of business with multithreaded software would be to wrap Win32 in a more sane abstraction.
MooseBoys@programming.dev · 2 pts · 3y
Most multi-threaded software was OS-specific, so they just used the OS threading utilities directly. Most serious multi-platform software writes their own abstraction on top of threads anyway.