4061 Session 21 (4/3). Today Thread Synchronization –Condition Variables –Monitors –Read-Write...
-
Upload
oscar-warren -
Category
Documents
-
view
232 -
download
0
Transcript of 4061 Session 21 (4/3). Today Thread Synchronization –Condition Variables –Monitors –Read-Write...
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)