Concurrency. Glossary

Transcription

1 Glossary atomic Executing as a single unit or block of computation. An atomic section of code is said to have transactional semantics. No intermediate state for the code unit is visible outside of the atomic transaction. concurrency the ability of different parts or units of a program, algorithm, or problem to be executed out-of-order or in partial order, without affecting the final outcome. concurrent Two or more operations are said to be concurrent if they can occur at the same time or appear to occur at the same time. The context switch plays a large role in concurrency. context switch The process of storing the state of a process or of a thread, so that it can be restored and execution resumed from the same point later. This allows multiple processes to share a single CPU, and is an essential feature of a multitasking operating system. The precise meaning of the phrase context switch varies significantly in usage. In a multitasking context, it refers to the process of storing the system state for one task, so that task can be paused and another task resumed. A context switch can also occur as the result of an interrupt, such as when a task needs to access disk storage, freeing up CPU time for other tasks. Some operating systems also require a context switch to move between user mode and kernel mode tasks. The process of context switching can have a negative impact on system performance, although the size of this effect depends on the nature of the switch being performed. critical section A critical section is a piece of code that accesses a shared variable (or more generally, a shared resource) and must not be concurrently executed by more than one thread. deadlock A state in which each member of a group is waiting for another member, including itself, to take action, such as sending a message or more commonly releasing a lock. Deadlock is a common 1

2 problem in multiprocessing systems, parallel computing, and distributed systems, where software and hardware locks are used to arbitrate shared resources and implement process synchronization. In an operating system, a deadlock occurs when a process or thread enters a waiting state because a requested system resource is held by another waiting process, which in turn is waiting for another resource held by another waiting process. If a process is unable to change its state indefinitely because the resources requested by it are being used by another waiting process, then the system is said to be in a deadlock deterministic An algorithm which, given a particular input, will always produce the same output, with the underlying machine always passing through the same sequence of states. invariant Invariants are properties of data structures that are maintained across operations. Typically, the correct behavior of an operation depends on the invariants being true when the operation begins. The operation may temporarily violate the invariants but must reestablish them before finishing. mutual exclusion A property of concurrency control, which is instituted for the purpose of preventing race conditions; it is the requirement that one thread of execution never enters its critical section at the same time that another concurrent thread of execution enters its own critical section nondeterministic In computer science, a nondeterministic algorithm is an algorithm that, even for the same input, can exhibit different behaviors on different runs, as opposed to a deterministic algorithm. There are several ways an algorithm may behave differently from run to run. An improperly constructed concurrent algorithm can perform differently on different runs due to a race condition. race condition When multiple threads of execution enter the critical section at roughly the same 2

3 time; both attempt to update the shared data structure, leading to a surprising (and perhaps undesirable) outcome. starvation A process is perpetually denied necessary resources to process its work. Starvation may be caused by errors in a scheduling or mutual exclusion algorithm, but can also be caused by resource leaks, and can be intentionally caused via a denial-of-service attack such as a fork bomb. 1 Concurrency We have learned about processes and threads (threads of control), which are important abstractions in computer science. They bring lots of benefits, including concurrent operation or concurrency. The key here is to know what is meant by the phrase at the same time and how that is accomplished. We will discuss this in light of our simplified processor execution model. Figure 1: CPU Execution Cycle This figure is deceptively simple. The key to understanding the subtlety is to recognize that the processing of instructions in a process can be interrupted after each instruction execution. Now we have to decide what is meant by instruction. Here, it will mean assembly language instruction as opposed to C Language instruction. This matters a lot! Now we can see why we spent so much time in CS 201 looking at the mapping of C Language features and instructions to assembly. We need to know how an instruction in a higher level language is put together from lower level primitives to see the issues with concurrency. 3

4 1.1 A Simple Example A very simple C expression is: i++; This is simply a single C Language expression that increments the value in the integer variable i. We need to know that, while this is a single C Language statement, it does not map to a single assembly language statement. Because is maps to more than one fetch decode execute check for interrupt cycle, we have to worry about concurrency. If the process is single-threaded, we have no concerns because the variable i is not shared. However, if we have more than one thread of control and the variable i is shared, then we have a problem. Let s see how this occurs. The C language expression i++ (or ++i ) compiles to at least 3 assembly language instructions load from <memory address of i> to <register> increment <register> store from <register> to <memory address of i> In terms of how these instructions get executed, our model yields this result for i++ (fetch load instruction) (decode load instruction) (execute load instruction) (check for interrupt) (fetch increment instruction) (decode increment instruction) (execute increment instruction) (check for interrupt) (fetch store instruction) 4

5 (decode store instruction) (execute store instruction) (check for interrupt) (continue ad infinitum) So there are three places where this sequence of instructions can be interrupted, although only 2 impact our example. Let s see how this could all go wrong with two threads executing at the same time. 5

6 Let s begin with the variable i having the value 3. Time Thread 1 Thread 2 load i into register R 1 = 3 incr register value R 1 = 4 interrupt! load i into register R 2 = 3 incr register value R 2 = 4 store register value at variable i i = 4 interrupt! store register value at variable i i = 4 Table 1: With Interrupted Code Sequence Incrementing variable i twice should result in the final value being i = i + 2 not i = i + 1! This execution is termed nondeterministic because the outcome of running the code cannot be determined from straightforward code inspection. The number of possible orderings of the critical section is O(n 2 ), or N 2, where N is the number of threads. We will use two threads in our examples as they suffice to see the issue clearly. Table 1 shows one possible ordering of this code. This ordering results in non-deterministic behavior. The result that we would prefer is one where either the code section for one thread runs to completion first and then the other thread runs to completion. Let s begin with the variable i having the value 3. 6

7 Time Thread 1 Thread 2 load i into register R 1 = 3 incr register value R 1 = 4 store register value at variable i i = 4 load i into register R 2 = 4 incr register value R 2 = 5 store register value at variable i i = 5 Table 2: Without Interrupted Code Sequence Now, the result of incrementing the variable i twice is now i = i + 2. This is one possible execution order for this code. This code gives us the answer we expect, but there is no guarantee that the code will be executed in this order every time. 1.2 Another Example The OSTEP text has an extended example in Chapter 26, Concurrency: An Introduction. example is long, but well worth looking at closely. The What we have demonstrated here is called a race condition (or, more specifically, a data race): the results depend on the timing execution of the code. With some bad luck (i.e., a context switch that occurs at untimely points in the execution), we get the wrong result. In fact, we may get a different result each time; thus, instead of a nice deterministic computation (which we are used to from computers), we call this result indeterminate 1, where it is not known what the output will be and it is indeed likely to be different across 1 In CS333, we will use the term nondeterministic 7

8 runs. Because multiple threads executing this code can result in a race condition, we call this code a critical section. What we really want for this code is mutual exclusion. This property guarantees that if one thread is executing within the critical section, the others will be prevented from doing so 2. When we say that a lock protects data, we really mean that the lock protects one or more invariant that applies to the data. 1.3 The Scheduler When the hardware posts a timer interrupt, an xv6 CPU will invoke kernel code that will eventually call the routine trap() in trap.c. Recall that each interrupt carries an interrupt number with it in order distinguish different interrupt types. For the timer interrupt in xv6, the system define IRQ TIMER is the symbol that stands in for the timer interrupt number (see traps.h). At the end of trap.c is this code. The code as shown is how the code will look after the C preprocessor has resolved the conditional compilation directives. if(myproc() && myproc()->state == RUNNING && tf->trapno == T_IRQ0+IRQ_TIMER && ticks%sched_interval==0) yield(); This code causes the routine yield() in proc.c to be run. The job of the yield() routine is to cause the current process to give up its CPU and allow the scheduler to select a new process to run on that CPU. This is the main way in which a context switch occurs in xv6. As you can probably guess, based on the routine name, this is called yielding the CPU. Now we can discuss the role that the scheduler plays in concurrency. The timer interrupt will occur at regular intervals, regardless of what the process currently using the CPU is up to. Since 2 OSTEP, Ch 26, pp

9 this occurs without regard to the process execution flow, it is termed an asynchronous event. Since it is not an action that the user program took in its code, it is also known as an involuntary context switch. This is in contrast to a voluntary context switch which the process knows will happen as a result of executing the code in the process; a system call results in a voluntary context switch. As we have seen, bad things can happen when the timing of the instructions are interleaved in a particular way. However, this is not guaranteed to happen each and every time. This is what makes concurrency bugs so hard to track down. In order to understand what could go wrong, we will assume that our scheduler is a malicious scheduler that is out to gets us, usually at the least convenient time. If we program defensively, so that the malicious scheduler cannot harm us, then we will have fewer concurrency issues to worry about. If we assume a malicious scheduler, then when we look at the previous example while remembering the execution cycle, we can clearly see the issue. Just because your program doesn t exhibit buggy behavior does not mean that you do not have a bug; you cannot prove a negative! Here is a simple thought problem for considering how mean the malicious scheduler can be. You are working for Big Corp on a high profile project. Assume that you have a very subtle concurrency bug in your code. Also assume that you will be giving the president of Big Corp and the company s largest customer a demo of your project next week. If you were the malicious scheduler, would it be meaner for you to cause the bug to occur now or wait until the demo next week? I ll note that you have a promotion and large bonus riding on a successful demo. Ouch! The problem with concurrency bugs is that they are not deterministic. They require a very specific set of conditions to exist for the bug to manifest. If the conditions are not present, the bug will not occur. This is very bad and very hard to find since it appears to occurs randomly. Since timing plays such a key role, this is a type of bug known as a timing bug. The solution is to use special programming techniques that control when another thread of control can access the same shared data as you. Not surprisingly, this is called concurrency control and there 9

10 are several good solutions. When done correctly, we remove the concern about the scheduler being malicious. The basis of our solution is called mutual exclusion. 2 Mutual Exclusion The problem which mutual exclusion addresses is a problem of resource sharing: how can a software system control access to a shared resource by multiple processes, when each process needs exclusive control of that resource while doing its work? The mutual-exclusion solution to this makes the shared resource available only while the process is in a specific code segment called the critical section. It controls access to the shared resource by controlling each mutual execution of that part of its program where the resource would be used. A successful solution to this problem must have at least these two properties: It must implement mutual exclusion: only one process can be in the critical section at a time. It must be free of deadlocks: if processes are trying to enter the critical section, one of them must eventually be able to do so successfully, provided no process stays in the critical section permanently 3. What is the main problem when we get this wrong and how can we program so that we guarantee that this problem cannot occur? 2.1 Deadlock If a process is indefinitely denied access to the resources that it requires, we term this starvation. Starvation in an operating system must be avoided at all times. Starvations is one of the outcomes of deadlock. 3 From Wikipedia 10

11 There are four conditions necessary and sufficient 4 for deadlock. Note that this statement is not a guarantee of deadlock. It only states that if these four conditions are present at some point in our program, that deadlock could occur. As always, timing plays a key role. The 4 Conditions Necessary and Sufficient for Deadlock 1. Mutual exclusion. Only one process can use the resource at any one time. 2. Hold and Wait. A process currently holding one exclusive resource is allowed to request another exclusive resource. 3. No preemption. Once a process holds a resource, it cannot be taken away. The held resource must be voluntarily given up by the process. 4. Circular wait. A cycle in the resource allocation graph must exist. Each process must be waiting for a resource which is being held by another process, which in turn is waiting for the first process to release the resource. See Fig. 2. We cannot have deadlock unless all four conditions hold. Therefore, the best strategy is to ensure that we violate at least one of these conditions whenever we require mutual exclusion 5. How we achieve mutual exclusion is tricky. Let s first take a look at an approach that seems promising, but does not actually reach our goal. 2.2 Rolling Your Own Intuitively, the programmer should be able to easily set the order of code execution within the process. This intuition is based on the single-threaded model with which most programming languages are implicitly taught. They are taught this way to be similar to a recipe, where each step comes one after 4 In mathematics, we might write this as, deadlock can occur if and only if these four conditions hold. 5 We will see later that semaphores violate hold and wait and can therefore avoid deadlock when used correctly. 11

12 Figure 2: Resource Allocation Graph Cycle the other. However, also like recipe, some code execution steps can occur out of order or concurrently with other steps. This makes it harder to get things right than you may initially suspect. There are three main concurrency control primitives that we will study: locks, condition variables, and semaphores. To illustrate the difficulty in controlling concurrency without special assistance by hardware, we will focus on locks. This will naturally lead into a discussion as to how locks are constructed and used in practice. In computer science, a lock or mutex (from mutual exclusion) is a synchronization mechanism for enforcing limits on access to a resource in an environment where there are many threads of execution. A lock is designed to enforce a mutual exclusion concurrency control policy 6. A lock supports two operation: lock and unlock. In xv6, the kernel function calls that provide wrappers for these 6 From Wikipedia 12

13 operations are called acquire() and release(). There are two types of locks: advisory and mandatory. A mandatory lock prevents access to data unless the lock is held. This is a strong guarantee that only one thread of control can access the critical section at a time. An advisory lock only provides a weak guarantee as the critical section can still be accessed without holding the lock (but this would be a bug). Since most programming languages only provide advisory locks, this is the type of lock we will discuss. When we think about putting a lock in our program, we usually want a mandatory lock, but since this is often not available, we must be aware of the hazards of using an advisory lock. Going forward, we will use lock to mean advisory lock. Logically, acquiring a lock is straightforward if(lock == 0) { // lock is free, set it to locked by my process lock = mypid; } and releasing a lock is even easier if (lock == mypid) lock = 0; Note that locks have a concept of lock ownership. At any one point in time, a lock my be held by no more than one thread 7 and the lock itself knows which thread owns it. While we do not show error states here, an attempt to unlock a lock that the thread does not hold must generate an exception of some type; usually a catastrophic program termination. In order to establish deterministic behavior, we require that lock and free are atomic operations. Eventually, we will use these atomic operations to build more elaborate atomic transactions which are blocks of code that have all or nothing, also called transactional, semantics. The xv6 acquire() and release() functions are organized as transactions. 7 That is, a lock may be held by exactly zero or one thread. 13

14 Our program cannot stop, or even delay, the running of the scheduler. Instead, we want to ensure that if the scheduler runs another thread or process that the new thread of control will not be able to access the data in our critical section. This is our goal and we will eventually get there! In this way, we not not have to worry about whether or not the scheduler is malicious. Transactions will play a large role. Our goal here has been to gain a deeper understand of, and appreciation for, concurrency. Next up: looking at how certain primitives can be used to avoid deadlock. 14