5. The Philosophers' Dinner – Threads and Concurrency

Learning Objectives

By the end of this chapter, you will be able to:

• Create synchronous and asynchronous multithreaded applications
• Apply synchronization to handle data hazards and race conditions
• Develop efficient multithreaded code with C++ thread library primitives
• Create threads using move semantics for multithreading closures
• Implement thread communication with futures, promises, and async

In this chapter, we will clarify the difference between basic terms in multithreaded programming, learn how to write multi-threaded code, find out which resources are provided by the C++ Standard Library for data access synchronization, learn how to prevent our code from encountering race conditions and deadlocks.

Introduction

In the previous chapter, we covered different types of dependencies and coupling in C++. We looked at how common API design patterns and idioms can be implemented in C++ and what data structures are provided by Standard Libraries, as well as their efficacy. We also learned how to work with functional objects, lambdas, and captures. This knowledge will help us learn how to write clear and efficient multithreaded programs.

The heading of this chapter contains the name of the most significant synchronization issue in concurrent programming – The Philosopher's Dinner. In a few words, this definition is as follows.

Three philosophers are sitting at a round dining table with bowls of sushi. Chopsticks are placed between each adjacent philosopher. Only one philosopher at a time can eat their sushi with two chopsticks. Perhaps each philosopher will take one chopstick and then wait until someone gives up another chopstick. Philosophers are an analogy for three working processes...

Synchronous, Asynchronous, and Threaded Execution

There is a nuanced distinction between the concepts of concurrent programming: synchronous, asynchronous, and threaded execution. To clarify it, we will start from the very beginning, with the concept of concurrent and parallel programs.

Concurrency

The idea of concurrency is more than one task being executed simultaneously. Concurrency doesn't specify how the simultaneity will be achieved. It only indicates that more than one task will be completed in a given period. Tasks can be dependent, parallel, synchronous, or asynchronous. The following diagram shows the concept of concurrent work:

Figure 5.1: The abstraction of the concurrency - a few people working on the same computer

In the preceding diagram, three people are working at the same time on one computer. We aren't interested in the way they do that, it's doesn't matter for this level of the abstraction.

Parallelism

Parallelism occurs when several tasks...

Review Synchronization, Data Hazards, and Race Conditions

The key challenge of multithreaded programming is knowing how the threads work with shared data. Shared data, also known as resources, are not only variables, but also file descriptors and environment variables, and even Windows registries. For example, if the threads just read the data, then there are no problems and no synchronization is required. However, if at least one of the threads edits the data, race conditions could arise. Usually, the operations on the data are not atomic, that is, they require several steps. Even the simplest increment operation of a numeric variable is performed in the following three steps:

1. Read the value of the variable.
2. Increment it.
3. Write the new value.

Due to the OSes interruptions, the thread can be stopped before it completes the operation. For example, we have threads A and B and have a variable that is equal to 0.

Thread A starts the increment:

1. Reads the value of the variable...

Futures, Promises, and Async

In the previous section, we learned almost all that we need to work with threads. But we still have something interesting to consider, that is, synchronizing threads using future results. When we considered condition variables, we didn't cover the second type of synchronization with future results. Now, it's time to learn about that.

Suppose there is a situation wherein we run some thread and continue with other work. When we need a result, we stop and check if it is ready. This situation describes the actual work with future results. In C++, we have a header file called <future> that contains two template classes which represent future results: std::future<> and std::shared_future<>. We use std::future<> when we need a single future result and use std::shared_future<> when we need multiple valid copies. We can compare them with std::unique_ptr and std::shared_ptr.

To work with future results, we need a special mechanism...

Summary

In this chapter, we learned about working with threads that are supported by the C++ Standard Library. This is fundamental if we want to write robust, fast, and clear multithreaded applications.

We started by looking at general concepts regarding concurrency – what parallel, concurrent, synchronous, asynchronous, and threaded execution is. Having a clear understanding of these concepts allowed us to understand the architectural design of the multithreaded application.

Next, we looked at the different issues that we faced while developing multithreaded applications, such as data hazards, race conditions, and deadlocks. Understanding these issues helped us build a clear synchronized architecture for our projects. We considered the synchronization concept on some real-life examples, which gave us a good understanding of the challenges that we may face while programming threaded applications.

Next, we tried to work with different Standard Library primitives for synchronization...