Chapter 1-Introduction

Like all other concurrent books, this book starts with listing the possible errors of auto-increment operators in Multi-concurrency scenarios.

Atomicity:

For auto-increment operations, any modern computer will implement this operation in three steps: loading data from memory to registers and adding data in registers, then write the added data to the memory.

If the initial counter value is 0, we will get 2 after the two threads are executed normally. However, if one thread executes Step 1 before the other thread executes step 3, both threads will save 1 to the memory, in this way, the increase of another thread will be lost (2 will not be obtained ).

Synchronization is an art used to prevent program errors from cross-execution paths. In a distributed system, synchronization is classified as communication: If the T2 thread receives a message from the T1 thread, in all possible cross-execution paths, all events that occur before the message is sent in T1 occur before T2 receives the message.

Some languages and systems ensure that only one thread is executing at the same time, and the thread context switch will occur at the point defined by the implementation.

It turns out that in the real-world programming model, basically all synchronization modes can be considered as an instance of atomicity or condition synchronization. Atomicity ensures that no other execution sequence exists during the execution of a command execution sequence. All cross-execution assumes that the underlying machine commands are atomic. Conditional synchronization ensures that a specific operation only appears if the prerequisite is true. Generally, this precondition is the completion of some operations in other threads.

The simplest way to implement atomicity is to force these threads to execute their operations with only one thread at a time. This policy is called mutual exclusion. The operation sets that are mutually exclusive are called critical zones.

If thread 1 obtains lock2 and thread 2 obtains lock3 before obtaining the target resource. There will be no limit to the two. One of the simplest solutions is that threads always give priority to the minimum number of locks. As a result, thread 2 does not obtain lock3 without obtaining lock2. However, in most cases, it is complicated to maintain such a static sequence. Another optional atomic implementation solution is the transaction memory. From the programmer's perspective, fine-grained locking is a means of achieving atomicity using a smaller critical section for large and complex operations. It is the responsibility of the programmer to ensure the correctness of the implementation. The transaction memory improves the abstraction, so that programmers can delegate this responsibility to the underlying system for implementation.

No matter whether Atomicity is through coarse-grained locks, fine-grained locks managed by programmers, or some transaction memory, all intents are atomic regions that are inseparable. In other words, it is any feasible execution path of the program-all possible cross-execution situations of its machine commands-which must be different from the time-based atomic operations, no other commands are executed in these atomic operations. In chapter 3, there are many ways to standardize these requirements, and more specifically several variants of linearity and serializability.

Conditional synchronization:

In synchronization research, a concurrent queue is sometimes called a buffer to define the boundary. It is an authoritative example that includes both synchronization and atomicity. As described above, the conditions in bounded buffer can be placed at the beginning of the critical section. In more complex cases, a thread executes an important task before it knows the conditions it will wait for in the critical section. For conditions to be true, another thread may modify the same data structure. A wait operation in the middle of the critical section may break the atomicity of the entire critical section. In chapter 7, we can see that only a simple synchronization mechanism for waiting in the critical section is supported. Other synchronization mechanisms allow conditions to appear anywhere in the critical section.

In addition to the critical section, conditional synchronization is also very useful. For example, synchronization barrier ensures that only the last step of all threads can be left.

It is attractive to assume that Atomicity is simpler than conditional synchronization. After all, atomicity can be considered as a subclass of conditional synchronization. A thread will be executed until there are no other threads in the critical section. The problem is the scope of the condition. For convenience, we take the condition into consideration the value of the variable rather than the State of the thread for the moment. Here, atomicity requires that all threads reach an agreement.

Spin and congestion:

For example, the synchronous mode is divided into two camps, and their implementation is also divided into two camps: they both adopt spin or congestion. Spin is a simple example. For example, conditional synchronization uses a general loop.

The simplest way to implement mutex is to use a hardware command Tas, which is available on most modern computers. Set a Boolean value to true and return the previous value. TAS can be used to implement simple spin locks.

,

The obvious disadvantage of busy waiting is that it wastes the CPU execution cycle. In a multi-application system, blocking is often used to allow the processor to execute other executable threads. The previous thread may be executed soon.

The software responsible for selecting which thread to execute is called the scheduler. In many systems, scheduling occurs at two different levels. At the operating system level, a kernel scheduler implements threads on the processor core. At the user runtime level, a user scheduler Implements user-level threads on the kernel scheduler. At any level, the Code implementing threads usually appears as a zombie of the library file interface, including a complete set of call subroutines. In addition, the language used by the kernel or application may provide specific thread management and synchronization, depending on the implementation of the compiler.

Schedulers at different levels have specific functions. The kernel-level scheduler prevents different applications from accessing each other's memory address to protect applications. User-level schedulers may be implemented in stack mode. To a greater extent, kernel or user-level schedulers have similar internal structures, and at different levels, rotation and blocking are useful.

Blocking does not need to constantly check the condition and lock status, but it will have performance costs when switching the program back and forth. If the average waiting time of a thread is twice the context switching time, the round training can be prioritized. When a thread is executed after each CPU core, round training is also a good choice, which usually occurs in embedded or high-performance systems. In the end, we will find in Chapter 7 that blocking (scheduling-based synchronization) must be implemented based on round training, because the data structure used by the scheduler also needs to be synchronized.

Chapter 1-Introduction