Reactiveswift Source code Parsing (11) Atomic implementation and defer delay, POSIX mutex, recursive lock

In this blog, let's talk about atomic operations in Reactiveswift , where we'll simply talk about POSIX mutexes and the concept of recursive locks and usage scenarios. And then we'll talk about the atomic Code implementation . Atomic is mainly responsible for the atomic operation under multi-threading , which is responsible for the synchronization consistency of shared resources. In atomic, POSIX mutexes and recursive locks are used. Before we talk about this, let's review the use of deferred execution defer in the swift language, as well as the use of defer in previous swift programming related blogs. Defer because the atomic is used to delay the operation, so we do a defer simple review below.

One, defer deferred execution

In this blog The reason why chat defer deferred execution , is because in the atomic Code implementation, uses the defer{} to add the lock for the operation. Specifically, it is locked before operation and then unlocked with defer{}, which we'll cover shortly. Defer deferred execution in Swift is more commonly used, and its usage is relatively straightforward. Below is an example that we have listed, which is simple. First we output a, then use the defer block to execute the statement of output B, then output C, and finally use the defer block output D, the specific code is as follows.

　　

When we look at the output of the above code, can we first predict the output, the output "ABCD" or "ACBC" or "acdb" ? Below is the output of the above code fragment. It is not difficult to see from the code snippet below that the result is "acdb". It is not difficult to see from the results that the order in which the defer{} blocks are executed is executed from behind before the scope ends.

　　

Based on the above code snippet and the output, we can draw a diagram of the operation below, as shown below. Because the diagram below is not complex, do not do too much to repeat here.

　　

Second, POSIX mutex lock

The concept of mutex is not too much to repeat, simply to prevent multiple threads at the same time to modify a shared area, resulting in data synchronization occurs when the lock added. Mutexes are mutually exclusive to a thread, meaning that a block of code that adds a mutex will allow only one thread to operate on that shared area at the same point in time, and other threads need to wait for the previous mutex to open before entering the block.

The Posixthreadmutex class below is a POSIX mutex encapsulated in the Atomic code implementation. In this code implementation, the main invocation of the C language of the thread mutex related functions. The use of the lower lock, and later talk about the atomic class will be used to the bottom of the mutex.

　　

Third, recursive lock

Next we look at the recursive lock, which is also used in the code implementation of atomic. " recursive lock " as the name implies is used in the recursive lock, ordinary locks in a thread can not be reused, that is, a normal lock is locked, you can not call the locking method again, this will be problematic. When the normal lock is unlocked, you can lock it. For the non-reusability of ordinary locks, we give the example below, as shown below.

　　

The code snippet above is simple, two times lock is executed for the normal lock, then executes our code block, then executes two times unlock. The procedure for using normal locks in this code is the same as for scenes with normal locks in recursive functions. When a recursive implementation function is performed, a normal lock is added when the first recursion is executed, and when the lock is not opened, the second recursive execution is locked. This scenario is the same as the code snippet above. Because normal locks are not reusable in the same thread, the code above generates a deadlock DeadLock. Below is the result of the code snippet above:

　　

We modified the nslock normal lock in the above code to Nsrecursivelock recursive lock, as follows. The code below will be executed correctly. Because a recursive lock can be used repeatedly in the same thread. The following are the specific examples:

　　

Since it is a recursive lock, then we will use recursive locks in the recursive function. When a recursive function performs the use of a lock, it essentially uses a lock multiple times. That is, it is locked again when a lock is unlocked. Below is a simple example of recursive locking used in recursive functions.

　　

Iv. implementation of specific codes for atomic atomic operations

After talking about the mutex and the recursive lock, let's take a look at the specific code implementation of the atomic operation Atomic class in Reactiveswift . Aotmic uses the above-mentioned POSIX mutex to do atomic operations. Below is the code implementation of the Atomic class.

It is not difficult to see from the code snippet below that both lock and unlock operations are performed when value is read and modified. Of course, the unlocked code is placed in the statement block of defer{}. There is also a recursiveatomic class in the atomic.swift file , which is responsible for recursive atomic operations. The difference between the recursiveatomic and the Atomic class is that the former uses a recursive lock, which is responsible for maintaining atomic operations in the recursive operation. The latter uses a mutex. The code for recursiveatomic is similar to the code of the Atomic class, so do not repeat it here.

　　

Today's blog will be here first, the next blog we will continue to parse the Reactiveswift framework of other content.

The above code GitHub share address:Https://github.com/lizelu/TipSwiftForRac

Reactiveswift Source code Parsing (11) Atomic implementation and defer delay, POSIX mutex, recursive lock