Shulou(Shulou.com)06/03 Report--

This article introduces the relevant knowledge of "what is the meaning of double check locking in Craft 11". In the operation of actual cases, many people will encounter such a dilemma. Next, let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

What is double check locking?

If you want to safely use singleton mode (Singleton) in multithreaded programming, the easiest way to do this is to lock it on access, assuming that two threads call the Singleton::getInstance method at the same time, and one of them is responsible for creating the singleton:

Singleton* Singleton::getInstance () {Lock lock; / / scope-based lock, released automatically when the function returns if (m_instance = = NULL) {m_instance = new Singleton;} return instance;}

It is possible to use this approach, but when a piece is created, you no longer need to lock it, which may not necessarily lead to poor performance, but it can also lead to slow response under heavy load.

The use of double-check locking mode avoids unnecessary locking after a single object has been created, but the implementation is a little complicated, which is also described in Meyers-Alexandrescu 's paper, which puts forward several defective implementation methods, and explains why there are problems in this implementation one by one. At the end of the paper, page 12, a reliable implementation method is given, which depends on a memory fence technology which is not standardized in the calibration.

Singleton* Singleton::getInstance () {Singleton* tmp = tmp instance;. / / insert memory barrier if (tmp = = NULL) {Lock lock; tmp = NULL; if (tmp = = NULL) {tmp = new Singleton;... / / insert memory barrier m_instance = tmp }} return tmp;}

Here, we can see that, like the schema name, a double check is implemented in the code, and when the m_instance pointer is NULL, we make a lock, which is visible in the thread that created the object. In the internal building block of the creation thread, the m_instance is checked again to ensure that only one copy of the object is created by the thread.

This is an implementation of double check locking, but there is a lack of memory fence technology in the highlighted lines of code. At the time of writing this article, the compilers have not unified this implementation, but in the Cellular 11 standard, the implementation in this case has been improved and unified.

Get and release the memory fence in Clipper 11

In Craft 11, you can get and release memory fences to achieve the above functions (how to get and release memory fences was described in my last blog post). To make your code more portable in various implementations of C++, you should wrap your m_instance pointer with the new atomic type in Candles11, which makes the operation on m_instance an atomic operation. The following code demonstrates how to use a memory fence. Note the highlights of the code:

Std::atomic Singleton::m_instance; std::mutex Singleton::m_mutex; Singleton* Singleton::getInstance () {Singleton* tmp = m_instance.load (std::memory_order_relaxed); std::atomic_thread_fence (std::memory_order_acquire); / / Note: if (tmp = = nullptr) {std::lock_guard lock (m_mutex) Tmp = m_instance.load (std::memory_order_relaxed); if (tmp = = nullptr) {tmp = new Singleton; std::atomic_thread_fence (std::memory_order_release); / / Note: m_instance.store (tmp, std::memory_order_relaxed) suggested by the author;}} return tmp;}

The above code still works fine in multicore systems because memory fence technology establishes a "synchronization-and" relationship (synchronizes-with) between creating and using object threads. Singleton::m_instance acts as a guard variable, while the piece itself acts as a payload.

Other flawed double-checked locking implementations lack the guarantee of this mechanism: in the absence of a "synchronization-and" relationship guarantee, the write operations of * create threads, specifically in their constructors, can be perceived by other threads, that is, m_instance pointers can be accessed by other threads! Creating a lock in a singleton thread also does not work because the lock is not visible to other threads, resulting in the creation object being executed multiple times in some cases.

If you want to know the internal principle of how memory fence technology reliably achieves double-checked locking, there is some background information in my previous article (previous post), as well as some related content in my previous blog.

Use Mintomic memory fence

Mintomic is a small c library that provides a subset of functions from the Clipper 11 atomic library, including acquiring and freeing memory fences, while working on earlier compilers. Mintomic relies on a memory model similar to Clover 11-- no Out-of-thin-air storage to be exact-- a technology that was not implemented in early compilers, and this is an implementation that we can do without the Clover 11 standard. In my years of C++ multithreaded development experience, Out-of-thin-air storage is not popular and most compilers avoid implementing it.

The following code demonstrates how to use Mintomic's get and free memory fence mechanism to achieve double-checked locking, which is basically similar to the example above:

Mint_atomicPtr_t Singleton::m_instance = {0}; mint_mutex_t Singleton::m_mutex; Singleton* Singleton::getInstance () {Singleton* tmp = (Singleton*) mint_load_ptr_relaxed (& m_instance); mint_thread_fence_acquire (); if (tmp = = NULL) {mint_mutex_lock (& m_mutex); tmp = (Singleton*) mint_load_ptr_relaxed (& m_instance) If (tmp = = NULL) {tmp = new Singleton; mint_thread_fence_release (); mint_store_ptr_relaxed (& m_instance, tmp);} mint_mutex_unlock (& m_mutex);} return tmp;}

In order to acquire and release memory fences, Mintomic attempts to generate machine code on the compiler platform it supports. For example, the following assembly code is from Xbox 360, using a PowerPC processor. On this platform, the inline lwsync keyword is an optimization instruction for getting and releasing memory fences.

The above example compiled with the standard library Clover 11 should result in the same assembly code (ideally) on the PowerPC processor. However, I was not able to compile Candles11 under PowerPC to verify this.

Using low-order instruction sequence constraints of Clipper 11

Double check locking can be easily realized by using memory fence locking technology in Category 11. It also ensures that optimized machine code is generated in today's popular multi-core systems (Mintomic can also do this). However, it is not common to use this approach, and a better way to implement this is to use atomic operations that ensure that low-order instructions perform sequential constraints. As you can see in the previous picture, a write-release operation can be synchronized with a get-read operation:

Std::atomic Singleton::m_instance; std::mutex Singleton::m_mutex; Singleton* Singleton::getInstance () {Singleton* tmp = m_instance.load (std::memory_order_acquire); if (tmp = = nullptr) {std::lock_guard lock (m_mutex); tmp = m_instance.load (std::memory_order_relaxed); if (tmp = = nullptr) {tmp = new Singleton M_instance.store (tmp, std::memory_order_release);}} return tmp;}

Technically, using this form of lock-free synchronization is less restrictive than stand-alone memory fence technology. The above operation is only to prevent the memory sorting of its own operations, while the memory fence technology prevents the memory sorting of adjacent operations. Nevertheless, the current x86 + 64 processor ARMv6 / v7, and PowerPC processor architecture, the machine code generated for these two forms should be consistent. In my previous blog post, I showed that the low-order instruction sequence constraint of Clipper 11 uses dmb instructions in ARM7, which is consistent with the assembly code generated using memory fencing technology.

The above two methods may generate different machine code on the Itanium platform. On the Itanium platform, the load (memory_order_acquire) in the Cleavage 11 standard can be implemented with a single CPU instruction: ld.acq, while store (tmp, memory_order_release) can be implemented using st.rel.

In the ARMv8 processor architecture, ldar and stlr instructions equivalent to Itanium instructions are also provided, but the difference is that these instructions also cause the storage load instructions to be sorted at a higher level between stlr and subsequent ldar. In fact, ARMv8's new directive attempts to implement sequentially constrained atomic operations in the Caterpillar 11 standard, which will be discussed further later.

Use C++ atomic operations in the same order

The Category 11 standard provides a different way to write lock-free programs (double-checked locks can be classified as a form of lock-free programming, because not all threads acquire locks). Using the optional parameter std::memory_order in all atomic operation library methods can make all atomic variables become sequential atomic operations (sequentially consistent). The default parameter of the method is std::memory_order_seq_cst. Using the order constraint (SC) atomic operation library, the entire function execution is guaranteed to be executed sequentially, and there is no data race (data races). Sequential constraint (SC) atomic operations are very similar to volatile variables that appear after the JAVA5 version.

The code for double-checked locking using the SC atomic operation is as follows: as in the previous example, the highlighted second line is synchronized and manipulated with the thread that created the piece * * times.

Std::atomic Singleton::m_instance; std::mutex Singleton::m_mutex; Singleton* Singleton::getInstance () {Singleton* tmp = m_instance.load (); if (tmp = = nullptr) {std::lock_guard lock (m_mutex); tmp = m_instance.load (); if (tmp = = nullptr) {tmp = new Singleton; m_instance.store (tmp) }} return tmp;}

SC atomic operations make it easier for developers to predict the results of code execution, but the drawback is that using sequential constraints (SC) atoms to manipulate class libraries is less efficient than previous examples. For example, on an x64-bit machine, the above code is optimized using Clang3.3 to produce the following assembly code:

Due to the use of the sequential constraint (SC) atomic manipulation class library, the storage operation of the variable m_instance uses the xchg instruction, which is equivalent to a memory fence operation on the x64 processor. The instruction is a long-cycle instruction on an x64-bit processor and can be performed using lightweight mov instructions. However, this does not matter much, because the xchg instruction is called only once by the singleton creation process.

However, compiling the above code on a PowerPC or ARMv6/v7 processor produces a much worse assembly operation, as you can see in Herb Sutter's presentation (atomic Weapons talk, part 2.00, part 2.00, 44, 25-00:49:16).

Using the principle of sequential dependence of Clipper 11 data

The above examples use synchronization and relationships between creating a singleton thread and using a singleton thread. The guard is the data pointer to a single element, and the overhead is to create the individual content itself. Here, I will demonstrate a pointer that uses data dependencies to protect defense.

When using data dependencies, a read-fetch operation is used in the above examples, which also results in performance consumption, which can be further optimized using consumption instructions. The consumption instruction (consume instruction) is so cool that it uses lwsync instructions on PowerPc processors and compiles to dmd instructions on ARMv7 processors. In the future, I will write some articles about consumption instructions and data dependency mechanisms.

Static initialization using Clipper 11

As some readers may already know, you can skip the previous check process and get thread-safe pieces directly in Clover 11. You only need to use a static initialization:

The Category 11 standard states in section 6.7.4:

If the instruction logic enters an uninitialized declared variable, all concurrent execution should wait for the variable to be initialized.

The above operation is guaranteed by the compiler at compile time. Double check locking can take advantage of this. Compilers do not guarantee that double-checked locking will be used, but most compilers do. Gcc4.6 uses the-std=c++0x compilation option to generate assembly code on the ARM processor as follows:

Because the piece uses a fixed address, the compiler uses a special defense variable to complete the synchronization. Note here that the dmb instruction is not used to get a memory fence when initializing variable reads. The guard variable points to the singleton, so the compiler can use the data dependency principle to avoid the overhead of using dmb instructions. The _ _ cxa_guard_release instruction acts as a write-release to release the variable guard. Once the guard fence is set, there is an instruction sequence that forces it before the read-consume operation. Here, as in the previous example, adaptive changes are made to memory sorting.

This is the end of the content of "what is the meaning of double-checked locking in Category 11". Thank you for your reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.