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?

  • auv_guy@programming.dev
    link
    fedilink
    English
    arrow-up
    6
    ·
    1 year ago

    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
    link
    fedilink
    English
    arrow-up
    3
    ·
    1 year ago

    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.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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.

    • corroded@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      1 year ago

      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
    link
    fedilink
    English
    arrow-up
    2
    ·
    edit-2
    1 year ago

    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.