Threads. Concurrency. What it is. Lecture Notes Week 2. Figure 1: Multi-Threading. Figure 2: Multi-Threading

Transcription

1 Threads Figure 1: Multi-Threading Figure 2: Multi-Threading Concurrency What it is 1. Two or more threads of control access a shared resource. Scheduler operation must be taken into account fetch-decode-execute-check for interrupt 2. Assumption of atomicity 1

2 3. Enforcement of atomicity (transactional semantics) Figure 3: Concurrency Terms Roll Your Own Shared counters / booleans. An int with values 0 and 1 int l o c k ( int v a r i a b l e ) f int s u c c e s s = 0 ; // assume we have f a i l e d t o g e t l o c k g i f ( v a r i a b l e == 0) f // u n l o c k e d v a r i a b l e == 1 ; s u c c e s s = 1 ; g return s u c c e s s ; 2

3 ... while (! l o c k ( mylock ) ) fg // wait, or spin, on t h e l o c k # now we hold the lock, we hope... Why doesn't this work? In this case, the scheduler is not our friend. We need to ensure that a critical section is treated atomically { all or nothing semantics. Locks Priorities for lock evaluation 1. Mutual exclusion. If we can't have mutual exclusion then the lock is worthless - less than worthless really 2. Fairness. Do waiting process/threads get a fair shot at the lock or do we have starvation issues. 3. Performance. Some consider this the top priority, but we need to lock to work properly and not have starvation before we can address performance. A really fast, but erroneous, implementation is useless. Why do spin locks degrade performance? Single CPU v. multiple CPU systems. Roll-Your-Own Turn o Interrupts (Intel cli). Captures the CPU. Very risky. Too general. Doesn't scale. Atomic CPU instructions Hardware designers MUST provide this capability. Software-only not possible. Test and Set; Atomic Exchange; TSL Intel has compare-and-exchange { xchgl. 3

4 Surround critical sections with a lock that prevents concurrent access by serializing access. In xv6, to lock we call acquire(lock) and unlock we call release(lock). Simple spins locks work, but waste CPU. X86 only has spin locks (spinlock.c) which calls out to x86.h for embedded assembly helper functions. Locks that sleep instead of wasting CPU. Benets and trade-os. Not as simple as it may seem. Fig from OSTEP Figure 4: OSTEP Fig Condition Variables How to signal a condition? Is other process ready? Have all the child processes exited? Is it my turn? CVs use a queue that is ordered (FIFO). When condition becomes TRUE, one of two things can happen 1. Wake up next process in Q 2. Wake up all process waiting in the Q Some issues: 4

5 1. What is some process grabs the resource before we wake some process up? Race condition - very bad 2. Required semantics: wait and signal 3. Order of lock acquisition and release { hint: always hold Producer-Consumer problem 1. Shared, bounded buer 2. One CV is very inecient. MESA v. Hoare semantics MESA - hint Hoare - direct hand-o Surprisingly, Mesa is easier to implement, get right (fewer edge cases), and scales well. Semaphores Basically can do anything. Binary - lock CV is a simple semaphore Semaphores have memory. They count! As Locks: Because locks only have two states (held and not held), we sometimes call a semaphore used as a lock a binary semaphore As CVs: Because the waiting thread (or threads) is waiting for some condition in the program to change, we are using the semaphore as a condition variable. Producer-Consumer with semaphores Reader-Writer Locks using semaphores The Dining Philosophers problem. Without forks. Other approaches. Issues Deadlock - 4 conditions. Break one and no deadlock circular wait hold and wait No Preemption Mutual exclusion 5

6 Atomic Reads When multiple threads want to read a shared data structure, concurrency control must still be used. This is many data accesses require several reads to memory to return an entire structure. Some processor manufacturers do, however, provide atomic access to certain data types. For example, here is information from the latest version Guaranteed Atomic Operations 1 The Intel486 processor (and newer processors since) guarantees that the following basic memory operations will always be carried out atomically: Reading or writing a byte Reading or writing a word aligned on a 16-bit boundary Reading or writing a doubleword aligned on a 32-bit boundary The Pentium processor (and newer processors since) guarantees that the following additional memory operations will always be carried out atomically: Reading or writing a quadword aligned on a 64-bit boundary 16-bit accesses to uncached memory locations that t within a 32-bit data bus The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically: Unaligned 16-, 32-, and 64-bit accesses to cached memory that t within a cache line 1 Intel 64 and IA-32 Architectures, Software Developer's Manual, Volume 3A: System Programming Guide, Part