4061 Session 21 (4/3)

Today

• Thread Synchronization– Condition Variables– Monitors– Read-Write Locks

Today’s Objectives• Explain the difference between mutual exclusion

and synchronization• Describe the purpose of a condition variable,

and the operations permitted on a condition variable– Use condition variables and mutex to solve the

producer-consumer problem

• Explain the purpose of a monitor• Describe the readers and writers problem

– List some trade-offs between using “strong reader synch” and “strong writer synch”

Admin

• Dewayne

• Many scholarship opportunities

• Quiz 4

• Read Chap 13-14 (thread synchronization)

Last Time

• Mutual Exclusion– How do I protect a shared resource from

concurrent access?

• Implementation of mutex (a few ways)

• POSIX mutex

On to Synchronization

• So, we can protect resources, now we want to have threads coordinate

• For example, we might want to wait for events to happen

• Or we want to execute unless we detect some program state

Let’s Look at Common Sync Mechanisms

• Condition Variable (+mutex)– Block, conditionally

• Monitor– High-level synchronization for programming

happiness

• Read-write lock– Conditionally allow parallelism

• Semaphore– More general version of mutex

Producer-Consumer Problem

• A.k.a. the Bounded Buffer Problem

• A classic problem used to study synchronization

• Two threads share a common, fixed-size buffer.– Producer thread fills the buffer– Consumer thread takes information from the

buffer

Producer-Consumer Problem (2)

• Problems– Producer wants to add an item to a full buffer– Consumer wants to remove an item from an

empty buffer

• Conceptual Solution– Producer should go to sleep if buffer is full,

consumer wakes up producer after next item taken

– (similar for empty buffer)

Solving Producer-Consumer, Step1

• Introduce some new calls:– sleep()– wakeup(otherThread)

• If you cannot take action, sleep

• If you complete an action that you think another thread might be waiting for, issue a wakeup

Producer-Consumer Problem with Race Condition

“Lost Wakeup Problem”

• A wakeup sent to a process that is not yet sleeping is lost, not accumulated

Mutex to the Rescue?• What about this?

if (count > 0) { pthread_mutex_lock(&lock); remove() count = count - 1; pthread_mutex_unlock(&lock);}

• Or, perhaps

while (count == 0) /* spin */ ;pthread_mutex_lock(&lock); remove();count = count - 1; pthread_mutex_unlock(&lock);

Condition Variables

• What if you could do this?

pthread_mutex_lock(&lock); while (count == 0) pthread_cond_wait(&nonzero, &lock);count = count - 1; pthread_mutex_unlock(&lock);

• Condition variables allow you to sleep– And you release the mutex so that you don’t

block others

CVs (2)

• Once you declare a condition variable, you may perform two (primary) operations on that variable– wait – causes the thread to block on the condition

variable, and automatically release the mutex it holds. On return from the function, the thread once again holds the mutex.

– signal – unblock at least one of the threads that are blocked on the specified condition variable cond (if any threads are blocked on cond)

Producer Consumer Problem Solved with Mutex+CV

mutex m;cond full, empty;

void insert(int i) { lock(m); if (count==N) wait(full); put(i); count++; if (count==1) signal(empty); unlock(m);}

int remove() {

/* todo */

}

Monitors

• Notice, in the last solution, we wished to lock at the beginning of the function and unlock at the end

• Common practice

• Can be baked into the programming language

Monitors (2)

• A monitor is a set of procedures

• Each monitor procedure:– Acquires a monitor-wide lock before doing

anything else– Holds the lock until it finishes or waits for a

condition

• Implemented using mutex

Producer Consumer Problem Solved with Monitors

Synchronization in Java

• Monitors + CVs• Use the “synchronized” keyword in a

method declaration.public synchronized int foo() {

/* only one thread in here */}

• You can also use synchronized statements (very similar)

Synchronization in Java (2)

• It is not possible for two invocations of synchronized methods/statements on the same object to interleave

• constructors cannot be synchronized

Synchronization in Java (3)

• Three methods for conditional waiting, all must be in synchronized blocks– wait

• CV wait semantics: sleep until awakened by another thread

– notify• CV signal semantics

– notifyAll• Like “broadcast” in POSIX

Readers and Writers Problem

• Imagine a database system with many processes trying to read and write concurrently– It’s ok if several processes read data at the

same time– But once a process starts to write, it needs a

mutex

• So perhaps we want to improve on the efficiency of enforcing mutex on all operations…

Strong Reader Synchronization

• One solution:– Readers

• First reader locks the write mutex.• Subsequent readers allowed in (increment

counter). • Last reader out releases the write mutex

– Writers• Lock write mutex, write, unlock

• Problems?

Strong Writer Synchronization

• Alternate solution:– Incoming readers are queued behind any

waiting writers

POSIX Read-Write Locks

• Calls are very similar to mutex

• The main difference is that you declare whether you are attempting to obtain a read lock or a write lock (through different calls)