dcsimg
Linux Today: Linux News On Internet Time.





More on LinuxToday


Linux Journal: Kernel Korner: Kernel Locking Techniques

Jul 18, 2002, 14:30 (3 Talkback[s])
(Other stories by Robert Love)

WEBINAR:
On-Demand

Re-Imagining Linux Platforms to Meet the Needs of Cloud Service Providers


"The fundamental issue surrounding locking is the need to provide synchronization in certain code paths in the kernel. These code paths, called critical sections, require some combination of concurrency or re-entrancy protection and proper ordering with respect to other events. The typical result without proper locking is called a race condition. Realize how even a simple i++ is dangerous if i is shared! Consider the case where one processor reads i, then another, then they both increment it, then they both write i back to memory. If i were originally 2, it should now be 4, but in fact it would be 3!

"This is not to say that the only locking issues arise from SMP (symmetric multiprocessing). Interrupt handlers create locking issues, as does the new preemptible kernel, and any code can block (go to sleep). Of these, only SMP is considered true concurrency, i.e., only with SMP can two things actually occur at the exact same time. The other situations--interrupt handlers, preempt-kernel and blocking methods--provide pseudo concurrency as code is not actually executed concurrently, but separate code can mangle one another's data.

"These critical regions require locking. The Linux kernel provides a family of locking primitives that developers can use to write safe and efficient code..."

Complete Story

Related Stories: