Linux Kernel Development Chapter 8. Kernel Synchronization Introduction Geum-Seo Koo Fri. Operating System Lab.

ClCu03 2 Introduction In a shared memory application Shared source are protected from concurrent access Because if multiple threads of execution access and manipulate the data Properly protecting shared resources can be tough Multiprocessing support implies that Kernel code can simultaneously run on two or more processors This chapter discusses The issues of concurrency and synchronization, as they exist in an operating system kernel

ClCu03 3 Critical Regions and Race Conditions Critical Regions Code paths that access and manipulate shared data Usually unsafe for multiple threads of execution to access the same resource simultaneously Race Condition(bug) If it is possible for two threads of execution to be simultaneously in the same critical region Synchronization Ensuring that unsafe concurrency is prevented and that race conditions do not occur

ClCu03 4 Why do we need protection? An ATM(Automated Teller Machine) int total = get_total_from_account(); /* total funds in account */ int withdrawal = get_withdrawal_amount(); /* amount user asked to withdrawal */ /* check whether the user has enough funds in her account */ if (total <withdrawal) error(“You do not have that much money!”) /* the user has enough money: deduct the withdrawal amount from her total */ total -= withdrawal; update_total_funds(total); spit_out_money(withdrawal); /* give the user their money */ P1 LOAD total(105)... SUB withdrawal(100)... STORE total(5) P2 LOAD total(105)... SUB withdrawal(10)... STORE total(95) Never happen total: 105

ClCu03 5 A specific computing example: i++; Thread 2 - get i(8) increment i(8->9) write back i(9) The Single Variable Thread 1 get i (7) increment i(7 -> 8) write back i(8) - Thread 1 get i (7) increment i(7 -> 8) - write back i(8) -- Thread 2 get i(7) - increment i(7->8) - write back i(8) Thread 1 increment i(7 -> 8) - Or: - increment i(8->9) Thread 2 - increment i(8->9) increment i(7->8) - The desired outcomeA possible outcome Possible outcome

ClCu03 6 Locking A lock provides Such a mechanism; it works much like a lock on a door Thread 1 try to lock the queue Succeeded: acquired lock access queue... unlock the queue... Thread 2 try to lock the queue failed: waiting.. waiting... succeeded: acquired lock access queue... unlock the queue the lock prevents concurrency

ClCu03 7 What Causes Concurrency, Anyway? The kernel has similar causes of concurrency Interrupts can occur asynchronously at almost any time, interrupting the currently executing code Softirqs and tasklets can raise or schedule a softirq or tasklet at almost any time Kernel preemption one task in the kernel can preempt another Sleeping and synchronization with user-space can sleep and thus invoke the scheduler, resulting in the running of a new process Symmetrical multiprocessing can be executing kernel code at exactly the same time

ClCu03 8 So, How Do I Know What Needs Protecting? Whenever you write kernel code, you should ask yourself these questions: Is the data global? Is the data shared between process context and interrupt context? If a process is preempted while accessing this data, can the newly scheduled process access the same data? Can the current process sleep(block) on anything? What prevent the data from being freed out from under me? What happens if this function is called again on another processor? What am I going to do about it?

ClCu03 9 Deadlocks A condition involving one or more threads of execution and one or more resources Each thread is waiting for one of the resources But all the resources are already held a four-way traffic stop self-deadlock

ClCu03 10 Deadlocks Deadly embrace or the ABBA deadlock Prevention of deadlock: a few simple rules Lock ordering is vital Prevent starvation Do not double acquire the same lock Complexity in your locking scheme invites deadlocks Thread 1 acquire lock A try to acquire lock B wait for lock B Thread 2 acquire lock B try to acquire lock A wait for lock A

ClCu03 11 Contention and Scalability Lock Contention Used to describe a lock that is currently in use, but that another thread is trying to acquire Scalability A measurement of how well a system can be expanded With a large number of processes, processors, and memory Kernel 2.6 Kernel locking is very fine-grained and scalability is very good

ClCu03 12 Locking and Your Code Whenever you write kernel code Whether it is a new system call or a rewirtten driver, protecting data from concurrent access needs to be a primary concern Linux kernel provides to ensure that your code is race and deadlock free