2

I've read: "Threads Cannot Be Implemented As a Library" (http://www.hpl.hp.com/techreports/2004/HPL-2004-209.pdf) and I agree with the main idea of that article. But, I have doubts: After all, before C++ model ( C++11) there was no native support for threading. But, Boost was able to provide a Thread as library. So, how is ( was) it possible/What I misunderstand?

Gilgamesz
  • 4,727
  • 3
  • 28
  • 63
  • 3
    There was no "native" support for threading in C with pthreads, and the paper uses that as an example of a thread library which appears to work, but has problems like: `The Pthreads specification prohibits races, i.e. accesses to a shared variable while another thread is modifying it. The problem here is that whether or not a race exists depends on the semantics of the programming language, which in turn requires that we have a properly defined memory model. **Thus this definition is circular**.` So thread libraries existed, and worked in practice, but it was hack-ish. – Peter Cordes Jul 29 '16 at 20:22
  • 3
    _Threads Cannot Be Implemented **Efficiently and Correctly** As a Library_. Boost::Thread suffered from many points outlined in article. Also relevant: http://stackoverflow.com/questions/6319146/c11-introduced-a-standardized-memory-model-what-does-it-mean-and-how-is-it-g – Revolver_Ocelot Jul 29 '16 at 20:23
  • "The Pthreads specification prohibits races, i.e. accesses to a shared variable while another thread is modifying it.". Wow, so how does it work? After all, taking a mutex is kind of race, isn't it? – Gilgamesz Jul 29 '16 at 20:40
  • It's literally the same thing as how the current C++ spec says that data races on non-atomic variables are UB. Two threads racing to take a mutex is fine, because that happens inside a pthreads function. The paper does explain its terminology. – Peter Cordes Jul 29 '16 at 21:43
  • @PeterCordes, thanks :) – Gilgamesz Jul 30 '16 at 08:31

2 Answers2

4

That paper is a little out of date, although the information is still relevant. Since then, C++11 introduced several updates to address these issues. In particular, C++11 added a more clearly defined memory model for dealing with multi-threaded programs. This is similar to Java, as described by the paper. C++11 also solidifies the concept of sequence points, now referred to as "sequencing", adds its own threading library (based on the one from boost), and adds an atomics library which includes several facilities for dealing with lock-free algorithms.

So, the C++ committee has improved the specification of the C++ language in terms of behavior within multi-threaded environments. And, they've clearly defined a minimum set of memory model expectations.

Its not perfect, but we're in a much better place than we were.

Information I would recommend:

  • Anthony Williams's book: "C++ Concurrency In Action"
  • Herb Sutter's "Atomic Weapons" talks.
ChrisG0x20
  • 281
  • 1
  • 6
  • 1
    Sequence points aren't new with C++11. According to the link you gave, C++11 actually replaced them with the concept of sequenced before / after, indeterminate (like `foo(i++, i++)`), or unsequenced (non-atomic data races fall into this category). But the key point is correct: C++11 modified its definition of sequencing to make sense in a multi-threaded C++ abstract machine. – Peter Cordes Jul 29 '16 at 21:48
2

Boost threads acted as a wrapper around the native threads provided by the underlying OS (Win32 threads or POSIX threads).

It also depended on the fact that the people writing the compilers had to define behavior above and beyond what's required by the standard itself to get things to work correctly.

Unfortunately, exactly what they defined (and how they defined it) varied somewhat, which limited how much Boost threads could do (though they have a fair number of macros to control how things like thread local-storage work, so you still get semi-portable access to quite a few facilities).

Jerry Coffin
  • 476,176
  • 80
  • 629
  • 1,111