• Here's the introverts example we've seen before—this time in C++! (Full version of this program is online here).

#include <iostream>       // for cout, endl
#include <thread>         // for C++ thread support
#include "ostreamlock.h"  // for CS110 iomanipulators (oslock, osunlock) used to lock down streams
using namespace std;

static void recharge() {
  cout << oslock << "I recharge by spending time alone." << endl << osunlock;
}

static const size_t kNumIntroverts = 6;
int main(int argc, char *argv[]) {
  cout << "Let's hear from " << kNumIntroverts << " introverts." << endl      
  thread introverts[kNumIntroverts]; // declare array of empty thread handles
  for (thread& introvert: introverts)
    introvert = thread(recharge);    // move anonymous threads into empty handles
  for (thread& introvert: introverts)
    introvert.join();    
  cout << "Everyone's recharged!" << endl;
  return 0;
}    

• Features:
  • We declare an array of empty (e.g. non-joinable) thread handles as we did in the C version. (The thread is a class relatively new to C++, and the holy grail of thread documentation pages sits right here.)
  • We install the recharge function into temporary threads that are then moved (via operator=(thread&& other)) into an until-then empty thread handle.
    • This is a new form of operator= that fully transplants the contents of the thread on the right-hand side into the thread on the left-hand side, leaving the thread on the right side as fully gutted, as if it were zero-argument constructed (e.g. an empty, non-joinable thread handle).
    • This is an important clarification, because a traditional operator= would produce a second working copy of the same thread, and we don't want that. We instead want to initialize one of the threads within the original array to be one that now runs code. This is how we do that.
  • The join method, not surprisingly, is equivalent to the pthread_join function we've already learned about.
  • The prototype of the thread routine—in this case, recharge—can be anything (although the return type is always ignored, so it should be void unless the same function is being used in a non-threaded context, and a return value is useful there).
  • Big point: operator<<, unlike printf, is not thread-safe.
    • Even worse: a series of daisy-chained calls to operator<< is certainly not guaranteed to be executed as one, phatty atomic transaction.
      
    • Simple solution: I've constructed stream manipulators oslock and osunlock to lock down and subsequently release access to an ostream so that two independent threads are never trying to simultaneulously insert character data into a stream at the same time. In essence, oslock and osunlock are bookending our first critical region, which is a block of code that must be executed in full before any other thread can enter the same region, lest we see evidence of synchronization issues.