Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong with the code to the right? Producer Consumer

Race Condition A Condition where the outcome depends on execution order count++, count-- do not use one machine instruction register1=count, register1=register1+1, count=register1 register2=count, register2=register2–1, count=register2 Suppose: P= producer, C= consumer, and count = 5 P: register = count // 5 P: register = register + 1 //6 C: register = count //5 C: register = register – 1 //4 P: count = register //6 C: count = register //4 Questions What is the final value for count? What other possibilities? What should be the correct value? Very difficult to test – can’t control when things happen

Critical Sections A block of instructions that must be protected from concurrent execution We cannot assume Process execution speed, although we can assume they all execute at some non zero speed Which process executes next Process execution order Race Condition: Concurrent access to shared data where the output depends on the order of execution

Critical-Section Solutions We need a protocol to guarantee the following: 1. Mutual Exclusion – There is a mechanism to limit the number of processes (normally one) that can execute in a critical section at the same time. 2. Progress - If no process is executing in a critical section, some waiting process must be allowed to enter. Bounded Waiting - A waiting process cannot be kept out of a critical section indefinitely. No assumptions can be made regarding process speed or scheduling order

Hardware Solutions Hardware atomic instructions test and set swap increment and test if zero The lab2 Kernel – cli communication mechanism is like a test and set: if ((cmd = cli.atomicRWCmd(null)) != null)

Operating System Synchronization Uniprocessors – Disable interrupts Currently running code would execute without preemption The executing code must be extremely quick Not scalable to multiprocessor systems, where each processor has its own interrupt vector Multiprocessor - atomic hardware instructions Spin locks are used; must be extremely quick Locks that require significant processing use other mechanisms: preemptible semaphores

Semaphores Synchronization tool that uses blocks acquire() { value--; if (value<0) { add P to list block } } release() { value++; if (value <=0) { remove P from list wakeup(P) } } Synchronization tool that uses blocks A Semaphore is an abstract data type Contains an integer variable (starts at 0) Atomic acquire method (P – proberin (Dutch for ‘to test’)) Atomic release method (V – verhogen (Dutch for ‘to increment’) Includes an implied queue

Semaphore for General Synchronization Counting semaphore the integer value allowed to take on values other than 0 or 1 can count available resources Binary semaphore integer value: 0 or 1 (one permit) Also known as mutex locks Note: Both implemented by the same class -- Semaphore java.util.concurrent.Semaphore sem = new Semaphore(n); sem.acquire() // critical section code sem.release()

Java Semaphores (Java 1.5) public class Worker implements Runnable { private Semaphore sem; public Worker(Semaphore sem) { this.sem = sem; } public void run() { while (true) { sem.acquire(); doSomething(); sem.release(); doMore(); } } public class Factory { public static void main(String[] args) { Semaphore sem = new Semaphore(1); Thread[] bees = new Thread[5]; for (int i=0; i<5; i++) bees[i] = new Worker(sem); for (int i=0; i<5; i++) bees[i].start(); } }

Blocking strategy It is possible that a thread needs to block while holding a mutex Issue a wait() call to release the mutex Another process must wake up the waiting thread (notify(), notifyAll(), interrupt()). Otherwise the waiting thread will never execute. Good design will minimize the time spent in critical sections

Deadlock and Starvation Deadlock – two or more processes wait for a resource that can never be satisfied. Let S and Q be two semaphores initialized to 1 P0 P1 S.acquire(); Q.acquire(); Q.acquire(); S.acquire(); // Critical Section // Critical Section S.release(); Q.release(); Q.release(); S.release(); P0 S.ac() then P1 O.ac() then P0 O.ac()-blocks then P1 S.ac()-blocks -- deadlock Starvation: Continual preemption (indefinite blocking) Could happen if the blocking list is LIFO Process priorities prevent a process from exiting a semaphore queue

The Bounded Buffer problem Text section 6.6.1 One or more producers add data to a buffer One or more consumers extract produced data from the buffer for service The buffer holds only n data elements (hence a bounded number) Solution with semaphores Three semaphores, mutex(1), full(n), and empty(n) Initialize mutex to 1, full to 0 and empty to n The full semaphore counts up, and the empty semaphore counts down

Bounded Buffer Semaphore Solution public void insert(Object item) { empty.acquire(); mutex.acquire(); buffer[in] = item; in = (in+1)%SIZE; mutex.release(); fill.release(); } public class BoundedBuffer { private static final int SIZE = 5; private Object[] buffer; private int in, out; private Semaphore mutex, empty, fill; public BoundedBuffer() { in = out = 0; buffer = new Object[SIZE]; mutex = new Semaphore(1); empty = new Semaphore(SIZE); fill = new Semaphore(0); } } public Object remove() { fill.acquire(); mutex.acquire(); Object item = buffer[out]; out = (out+1)%SIZE; mutex.release(); empty.release(); return item; } Demonstrates binary and Counting semaphores

The Readers-Writers Problem Data is shared among concurrent processes Readers: only read the data set, without any updates Writers: May both read and write. Problem Multiple readers can read concurrently Only one writer can concurrently access shared data Shared Data Data set -- next slides simplify the lab problem to a single shared string Semaphore mutex initialized to 1. // writer must have Semaphore db initialized to 1 // Acquired by the first reader Integer readerCount initialized to 0 counting upwards. Note: The best solution is to disallow more readers while a writer waits. Otherwise, a writer may starve.

Class describing shared data class DataLock // named Database in the text { private int readers; private Semaphore mutex, db; public DataLock() { readers = 0; mutex = new Semaphore(1); db = new Semaphore(1); } public void acquireRead() // First reader acquired db { mutex.acquire(); if (++readers==1) db.acquire(); mutex.release(); } public void releaseRead() // Last reader released db { mutex.acquire(); if (--readers==0) db.release(); mutex.release(); } public void acquireWrite() {db.acquire();} public void releaseWrite() {db.release();} } How would we disallow more readers after a write request? (add private boolean writerWaiting; // controlled by mutex)

Reader / Writer Classes class Reader extends Thread { private Database db; private Thread parent; // to make syscalls public Reader(Database db, ReaderWriter parent) {this.db = db; this.parent = parent;} public void run() { while(true) { sleep(500);db.acquireRead(); doRead(); db.releaseRead();} } } class Writer extends Thread { private Database db; private Thread parent; public Writer(Database db, ReaderWriter parent){ this.db = db; this.parent = parent;} { while (true) { sleep(500); db.acquireWrite(); doWrite(); db.releaseWrite();} } } Hints for the lab project make an array of Database objects add throws InterruptedException to the methods Randomly choose the sleep length See demos/lab3.zip

Monitors A high-level abstraction integrated into the syntax of the language Only one process may be active within the monitor at a time Monitor without condition variables

Java Monitors Every object has a single monitor lock A call to a synchronized method does the following: Lock Available: acquires the lock Lock Not available: thread blocked and added to the entry set Non synchronized methods ignore the lock Lock released when a synchronized method returns The entry queue algorithm varies (normally FCFS)

Java Synchronization Inside a synchronized method: wait(): block the thread, release lock, move thread to the wait set. notify() An arbitrary thread from the wait set moves to the entry set. A thread not waiting for that condition reissues a wait() notifyAll() All threads in the wait set move to the entry set. Threads not waiting for that condition call wait again Notes: notify() & notifyAll() are ignored if the wait() set is empty wait() & notify() are single condition variables per Java monitors Java 1.5 adds additional condition variable support

Java Bounded Buffer with Monitors public class BoundedBuffer { private int count, in, out; private Object buf; public BoundedBuffer(int size) { count = in = out = 0; buf = new Object[size]; } public synchronized void insert(Object item) throws InterruptedException { while (count==buffer.length) wait(); buf[in] = item; in = (in + 1)%buf.length; ++count; notifyAll(); } public synchronized Object remove() { while (count==0) wait(); Object item = buf[out]; out=(out+1)%buf.length; -- count; notifyAll(); return item;} }

Java Readers-Writers with Monitors public class Database { private int readers; private boolean writers; public Database() {readers=0; writers=false; } public synchronized void acquireRead() throws InterruptedException { while (writers) wait(); ++readers; } public synchronized void releaseRead() { if (--readers==0) notifyAll(); } public synchronized void acquireWrite() { while (readers>0||writers) wait(); writers=true;} public synchronized void releaseWrite() { writers=false; notifyAll(); } }

Block Synchronization Synchronization on an object other than the object executing a synchronized method. “Scope” of a lock (not lexical scope) time between acquire and release A synchronized block might have shorter scope than an entire synchronized method How to do it Instantiate a lock object Use the synchronized keyword around a block Use wait() and notify() calls as needed inside the block Example Object lock=new Object(); synchronized(lock) { // somecritical code. lock.wait(); // more criticalcode lock.notifyAll(); } Question: What's wrong with: synchronized(new Object()) {// code here} Reference to the synchronizing object is not stored in a variable, so is lost.