Re: Threading in new C++ standard

On Apr 25, 5:04 pm, Szabolcs Ferenczi <szabolcs.feren...@gmail.com>
wrote:


If the only "language element" your world-view will admit is a new
syntactic construct, then you're right and the new C++ standard does
not contain any language elements to support threading. However,
that's an extremely limiting definition, not shared by very many
people.

A comprehensive memory model is *required* for correct threaded code,
and it's something C++ does not yet have. At the most basic level, a
memory model is a set of rules dictating what writes are and are not
allowed to affect a given read. In the following simple example:

struct foo {
  short a;
  short b;
};

foo a_foo;

a memory model provides hard and fast rules about whether or not a
read of a_foo.b is allowed to be affected by writes to a_foo.a, or to
a_foo itself. Note that this doesn't necessarily need to involve
threads in the definition: the rules will hold under all (valid)
executions of the program possible for a conforming implementation,
including multithreaded executions.

If there is a comprehensive memory model that allows it (as with the
one in the upcoming C++ standard), *then* a library can provide the
threading primitives that are correct with respect to that memory
model. Without the rules a memory model provides, you can't state
that

struct bar {
  short a;
  short b;

  pthread_mutex_t a_mtx;
  pthread_mutex_t b_mtx;
};

bar a_bar;

void thread_a () {
  pthread_mutex_lock (&a_bar.a_mtx);
  a_bar.a++;
  pthread_mutex_unlock (&a_bar.a_mtx);
}

void thread_b () {
  pthread_mutex_lock (&a_bar.b_mtx);
  a_bar.b = 5;
  std::cout << a_bar.b << std::endl;
  pthread_mutex_unlock (&a_bar.b_mtx);
}

is either correct *or* incorrect if thread_a and thread_b are called
on different threads, because nothing guarantees that the write to
a_bar.a will not affect a_bar.b.

*That's* the nature of the language support being added. It's not
about syntax: it's about semantics and rules. The tools for creating
and synchronizing threads are being added to the library because there
is no need to modify the language to support them, and because
modifying the C++ language itself is fraught with peril. The language
is being extended to provide rules that allow the library to be both
portable and correct.

-o