C ++ Multithreading

Many C ++ authorities, or even the authority of computer science, regard parallel or micro-level multithreading as the topic of the next revolution.

I haven't cared about these things for a long time. I read some related articles today, which is very enlightening. The first part is proposal n1680: Memory Model for Multithreaded C ++.

A memory model describes the behavior of threads with respect to basic memory operations-mainly reads and writes of variables potentially accessible implements SS multiple threads. The main questions addressed by a memory model include:

Atomicity: Which memory operations have indivisible effects?

Visibility: under what conditions will the effects of a write action by one thread be seen by a read by another thread?

Ordering: under what conditions are sequences of memory operations by one or more threads guaranteed to be visible in the same order by other threads?

In addition to defining this, we also talk about the "adopt" Java model in the future because the Java memory model is quite mature.

In n1876, some things are more specific, such as atomicity:

For example, atomically updated integers wocould provide operations such as load atomically read the value of the integer.

Store atomically replace the value of the integer.
Fetch and add atomically Add a value to the integer.
Store with release ordering semantics atomically replace the value of the integer, and ensure that all prior memory operations executed by this thread become visible to other threads before the update.
Load with acquire ordering semantics atomically load the value of the integer, and ensure that all later memory operations stored med by this thread become visible after the load.

In fact, the latter two have some similarities with locking in terms of semantics, but they use atomicity, visibility, and ordering to define them as a hint of lock-free. Furthermore, their semantics is weaker than locking. For example, the third one only indicates that the memory operation must be visible to other threads, while locking means that access by other threads is not allowed at the same time. Indeed, the performance benefit of the lock free algorithm is great, and there are no locking problems. On the HP website, Boehm provides a very rough model:

Enum ordering_constraint {none, acquire, release, ordered };


Template <class T>
Class atomic {
Public:
Static bool basics_supported ();

Template <ordering_constraint C>
Void store (const T &);

Template <ordering_constraint C>
T load ();

Static bool cas_supported ();

Template <ordering_constraint C>
Bool CAS (const T & old, const T & new_val );
};

Template <class T = emulated_atomic <int>
Class atomic_int: Public t {
Public:

Template <ordering_constraint c>
T fetch_and_add (const T &);
Template <ordering_constraint c>
T fetch_and_add1 ();

Template <ordering_constraint c>
T fetch_and_sub1 ();
Template <ordering_constraint c>
T fetch_and_and (const T &);
Template <ordering_constraint c>
T fetch_and_or (const T &);
};

I believe that for programmers, this code is clearer than a long article. Atomic can be used to establish a data structure with atomic operation semantics and provide direct support for CAS. Because the lock-free algorithm is hard to write, using the lock-free data structure may be a better choice.