Linux (kernel analysis): 28 --- kernel synchronization of (critical region, race conditions, synchronization, lock, common core concurrency, SMNP UP and configuration options, contention and scalability lock (lock granularity))
Method many years ago, yet in Linux support for symmetric multi-processor time, to avoid concurrent access to data is relatively simple. In a single processor when , and only when the interrupt occurs, or explicitly request to reschedule the kernel code, the time to perform another task, the data can be available concurrent access . Therefore, early kernel development work is now much simpler compared to
But the halcyon days of the year gone, from 2.0, the kernel starts a symmetric multi-processor support , and support for it since then constantly strengthened and improved. Support for multi-processor means that the kernel code can run on two or more processors at the same time . Therefore, if not protected, kernel code to run on two different processors entirely possible concurrent access to shared data at the same moments. With the advent of the 2.6 kernel, Linux kernel has developed into a preemptive kernel , which means (of course, still refers to the absence of added protection) scheduler can preempt the running kernel code at any time, reschedule another process execution . Now, there are many portions of the kernel code can be executed synchronously, but they must be properly protected
Second, the critical region, race conditions, synchronization concept
The so-called critical region (also known as the critical period) to access and manipulate the code segment is shared data . Multiple execution threads concurrently access the same resources are usually insecure, in order to avoid concurrent access, the programmer must ensure that these critical section of code execution atomically - that is, the operation can not be interrupted before the end of execution, it as the entire critical area is an integral part of the same instruction
If two threads of execution may be in the same critical section concurrently, then this is the program contains a bug. If this does happen, we call it competitive conditions (race conditions), so named because here there will be competition thread. Chance of this happening are often very small - because of errors caused by competition very difficult to reproduce, it will be very difficult to debug this error
Avoid concurrent and prevent race conditions called synchronous (synchronization)
Third, the lock
There are various forms of lock, and locking the particle size range also varies --Linux itself implements several different locking mechanisms. The difference between the major lock mechanism that: When the lock is already held by another thread, and therefore can not conduct when using performance - will simply perform a number of busy waiting when the lock is contention, while others will lock the current task to sleep until lock is available
Fourth, the common concurrent kernel
Kernel may have a similar cause of concurrent execution. They are:
Break the code asynchronous interrupts can occur at almost any time, it is subject to the big end of the currently executing -
Soft interrupt and tasklet - kernel interrupt can wake up or scheduling software and tasklet, break off at any time of the currently executing code
Kernel preemption - because the kernel has preemption, the kernel task may be preempted by another task
Sleep and synchronization with the user space - could sleep in the kernel execution process, which will wake up the scheduler, resulting in scheduling a new user process execution
Symmetric Multi Processing - two or more processors can execute code simultaneously
Break the security code, SMP security code, to seize the security code
The interrupt handler to avoid concurrent access security code is referred to as interrupt security code (interrupt-saft), in a symmetric multiprocessing machines in the security code to avoid concurrent access are called SMP security code (SMP-safe), the kernel to avoid concurrent access security code called upon to seize the preemptive security code (preempt-safe)
Five, SMP and UP configuration options
Because the Linux kernel can be configured at compile time, so you can cut out the core for a given machine. More importantly, CONFIG_SMP kernel configuration option controls whether to support SMP. Many problems locking on a single processor does not exist, so that when CONFIG_SMP not set, unnecessary code will not be incorporated into a single image for the kernel processor. Doing so allows a single processor machine to avoid the overhead of using a spin lock brings. The same technique is also applicable to CONFIG_PREEMPT (kernel preemption allows configuration options). This design is really excellent - the kernel only maintain some simple basic resources, a variety of locking mechanism when the need may at any time be compiled into the kernel. On different architectures, CONFIG_SMP CONFIG_PREEMPT set a different amount, lock included in the actual compilation time is different
In the code, to provide adequate protection for most worst case, for example, a kernel preemption of the SMP, and consider the case where all the
Sixth, contention and scalability locks
Lock contention
Lock contention, referred contention , means that when the lock is being occupied, there are other threads trying to acquire the lock. He said a lock contention in a high state, meaning there are a number of other threads waiting to acquire the lock
As the role of the program is to lock in a serial manner access to resources, so the use of locks will undoubtedly reduce system performance . It is highly contention (frequently being held, or hold a long time - both even worse) the lock will become a bottleneck in the system, seriously degrade system performance. Even so, compared to the snatch several threads share resources with each other to shreds, and made a kernel panic, or this synchronization protection come a little better . Of course, if there is a way to solve the height of contention, but the better
Expansibility
Scalability is a measure of the system can be extended degree . For the operating system, and we will process a lot, a lot, or a lot of memory and other processors linked when talking about scalability. In fact, any computer components can be measured can relate scalability. Ideally, doubling the number of processors should cause the system to double the processing performance. In fact, it is impossible to achieve
Since the version 2.0 kernel introduced multi-processing support, Linux cluster processor scalability greatly improved. Just joined in Linux support for multiple processors, when only one task at a time execute in the kernel; in version 2.2, when the locking mechanism of the development of the fine-grained locking , this restriction will be removed, and in 2.4 and later, the core locking granularity become more sophisticated. Now, in version 2.6 Linux kernel, the kernel plus locks are very fine granularity, scalability is also very good
Locking granularity locking is used to describe the size of data protection . A lock protection too thick chunk of data - all of the data structures, such as, a subsystem used: on the contrary, a too fine a small lock protected data - for example, an element of a large data structure. Neither in the actual use, the lock locking the vast majority are in the range between the two extremes, is a protected subsystem is not complete a separate element, but may be a separate data structure. Many lock design is very rough in the beginning, but when the lock contention becomes a serious problem with the design evolves to a more sophisticated locking direction
Discussed in the previous run queue is a lock from coarse to fine examples. In version 2.4 and earlier kernel, scheduler has a separate dispatch queue (Recall that the scheduling queue is a list composed by a scheduling process), in earlier versions of the 2.6 kernel series, O (1) scheduler program with a separate processor for each run queue, each queue has its own lock, the lock then refined to a global lock each processor has its own lock. This is an important optimization, because the run queue lock on large machines are racing by, in essence, every time you want to put on a single processor to the next whole scheduling process scheduler. In the version of the 2.6 kernel series, CFS scheduler further enhance the scalability lock
In general, scalability is a good thing, because it can improve the performance of Linux on the larger, more powerful processing capability of the system . But blindly "improve" scalability, but it will guide performance Linux SMP and UP on small machines is reduced, which is small because the machine could not use a particularly fine lock , the lock was too small and will only increase the complexity and plus large overhead. Consider a linked list, the initial program might be locked with a lock to protect the list, later found in the cluster has a processor machines, when individual processors require frequent access to the list, when only a single lock has become extensions of the bottleneck. To address this bottleneck, we will lock the entire list had become for each node in the linked list are adding their own lock, so that, if you want to read and write nodes, you must first obtain the corresponding node lock. After the lock granularity thinner, multi-processor access to the same node, only a lock contention. But then lock contention is still not completely avoid, then, can provide a lock on each node for each element in it? (The answer is: not) Strictly speaking, even if such a thin lock can perform well on a large scale SMP machine, but it is reflected in the dual-processor machine what will happen? If the race were not apparent in the dual-processor machine lock, the lock will increase the excess overhead, resulting in a great waste
Anyway, scalability is very important and needs to be carefully considered. The key is in the lock of the beginning of the design should take into account to ensure good scalability. Because even on small machines, if the lock is too coarse to important resources, it is also likely to result in system performance bottlenecks. Lock add too thick or too small, the difference is often only a fine line between. When serious lock contention, lock too thick will reduce the scalability; and when lock contention is not obvious, too small lock will increase overhead, bringing waste, both of which can cause system performance degradation. But remember: early in the design should be simple locking scheme, only when the need to further refine the locking scheme. Essence is keep it simple
