With C++14 came reader-writer locks. The idea is straightforward and promising. Arbitrary reading threads can access the critical region at the same time, but only one thread is allowed to write.

If the previous post showed something, it's that you should use mutexes with great care. That's why you should wrap them in a lock.

Usage of mutexes seems extremely simple. There is a critical section in the code, which can only be accessed by a single thread at any point of time. It's ensured by a mutex m. The calls m.lock() and m.unlock() guarantee this exclusivity. But, the devil is in the details.

I created a repository for the source code. It's on GitHub and has the name ModernesCppSource:
https://github.com/RainerGrimm/ModernesCppSource.git

Thread creation is easy. Call  std::thread, and a new thread will be created. The thread gets a work package and starts it immediately. The creator of the thread (the Parent) has to take care of the created thread (the child). The parent should wait until their child is done with its task or has to detach itself from its child. The child thread can get its payload task arguments by copy or by reference.

One of the biggest challenges of thread management begins when the threads share non-const data

A thread gets its data by copy or by reference. By default, you should use by copy. Why? In case your thread gets its data by reference, you have to be extremely careful about the lifetime of the arguments.

The parent has to take care of their child. This simple idea has big consequences for a thread lifetime. The following program starts a thread, that displays its ID.

After a lot of discussion with my proofreaders, we finally have a process to publish the articles.

With the new C++11 Standard, C++ faces the first time challenges of multicore architectures. The 2011 published standard defines how a C++ program has to behave in the presence of multiple threads. The C++11 multithreading capabilities are composed of two components. This is, on the one hand, the defined memory model, which is on the other hand, the standardized threading interface.