Using Mesa-style monitors

n Monitors combine:
n Locking for mutual exclusion
Condition variables to represent scheduling constraints
Threads: Wrap Up
n

lock.Acquire(); lock.Acquire();

while (!ready) { ready = 1;

Arvind Krishnamurthy
sleep on cond;
Spring 2001 } signal(cond);

lock.Release(); lock.Release();

Using Broadcasts Readers/writers problem

n Can always replace a “signal” by a “broadcast” operation n Motivation
n Performance implications, but no correctness problems n shared database (e.g., bank balances / airline seats)
Two classes of users:
Sometimes need to use broadcast if you want to wake up all the
n
n
n Readers --- never modify database
waiting threads
n Writers --- read and modify database

lock.Acquire(); lock.Acquire(); n Using a single lock on the database would be overly restrictive
n want many readers at the same time

n only one writer at the same time

while (!ready) { ready = 1;
sleep on cond;
} broadcast(cond); n Constraints
n Readers can access database when no writers (Condition okToRead)
lock.Release(); lock.Release(); n Writers can access database when no readers or writers (Condition
okToWrite)
n Only one thread manipulates state variable at a time

Design Specification Solving readers/writers

n Reader
Reader/Writer() {
n wait until no writers
lock.Acquire();
n access database
while (!ok to proceeed) {
n check out - wake up waiting writer
Wait(&lock);
n Writer
}
n wait until no readers or writers
update state variables;
n access data base
lock.Release();
n check out --- wake up waiting readers or writer
Access DB;
n State variables lock.Acquire();
n # of active readers (AR); # of active writers (AW); update state variables;
n # of waiting readers (WR); # of waiting writers (WW); if (someone is waiting)
Signal(&lock);
n Lock and condition variables: okToRead, okToWrite lock.Release();
}

1
 Solving Readers/writers Solving readers/writers
n Reader: Reader() { Writer() {
n When ok to proceed? AW = 0 lock.Acquire(); lock.Acquire();
while (AW > 0) { while ((AW+AR) > 0) {
n What to wait on? okToRead condition variable WR ++; WW ++;
n How to update state variables? AR++ or WR++ or AR– or WR— okToRead.Wait(&lock);
okToWrite.Wait(&lock);
When to signal? If AR == 0 && WW > 0, signal okToWrite WR --;
n WW --;
}
AR++; }
AW++;
n Writer: lock.Release();
lock.Release();
n When ok to proceed? AR = 0 & AW = 0 Access DB;
Access DB;
n What to wait on? okToWrite condition variable lock.Acquire();
AR--; lock.Acquire();
n How to update state variables? AW++ or WW++ or AW– or WW—
if (AR == 0 && WW > 0) AW--;
n When to signal? okToWrite.Signal(&lock); if (WW > 0) okToWrite.Signal(&lock);
n If waiting writers, signal okToWrite lock.Release(); else if (WR > 0) okToRead.Broadcast(&lock);
}
n If waiting readers, broadcast okToRead lock.Release();
}

One-way-bridge problem One-way bridge solution

n Problem definition Lock lock; ExitBridge(int direc) {
n a narrow light-duty bridge on a public highway Condition safe; // safe to cross bridge lock.Acquire();
int currentNumber; // # of cars on bridge currentNumber--;
n traffic cross in one direction at a time
int currentDirec; // current direction safe.signal(lock);
n at most 3 vehicles on the bridge at the same time (otherwise it will lock.Release();
collapses) ArriveBridge(int direc) { }
lock.Acquire();
while (! safe-to-cross(direc)) {
n Each car is represented as one thread: safe.wait(lock)
} safe-to-cross(int direc) {
OneVechicle (int direc) currentNumber++; if (currentNumber == 0)
currentDirec = direc; return TRUE; // always safe if empty
{ lock.Release(); else if ( (currentNumber < 3) &&
ArriveBridge (direc); } (currentDirec == direc) )
… crossing the bridge …; return TRUE;
else
ExitBridge(direc);
return FALSE;
} }

Implementing Monitors Second Attempt

n Can we use semaphores to implement condition variables? n Release the lock then…
Wait(Lock *lock) {
lock->Release();
n Simple attempt: semaphore->P();
Wait() { semaphore->P(); } lock->Acquire();
Signal() { semaphore->V(); } }
Signal() { semaphore->V(); }

n Solution is not relinquishing the lock: n Too much history! Semaphore updates are remembered for ever
n Consider behavior of condition variables:
lock.Acquire();
lock.Acquire(); n What if thread signals and no one is waiting? No op.
n What if another thread later performs a “wait”? It blocks.
if (!condition)
Wait(); Signal(); n Compare with behavior of semaphores:
n What if thread V’s and no one is waiting? Increment
lock.Release(); n What if another thread later performs a P? Decrement and continue
lock.Release();

2
 Third Attempt Implementing Monitors
n Does this fix the problem? Using one semaphore for each waiting thread --- making sure it indeed gets
the message when it is signalled.
Signal()
{
class Condition { List waitQueue; }
if semaphore queue is not empty
semaphore->V(); Condition::Wait(Lock* lock) { Condition::Signal(Lock* lock) {
} Semaphore *w; Semaphore *w;
n Well, it is cheating…
w = new Semaphore (0); if anyone on waitQueue {
n But also wrong: add w to the waitQueue; Take a waiting element off
n Race condition: signaller can slip in after lock is released and before lock->Release(); and name it w;
wait. w->P(); w->V();
lock->Acquire(); }
n Signal is lost. What did we violate: the atomic release + wakeup
delete w; }
property
}

Concurrency Summary Cautionary Tale

n Basic idea in all of computer science is to abstract n Microsoft OS/2: used threads for everything – window systems,
communication between programs, etc.
complexity behind clean interfaces
n Reality: single CPU, interrupts n System created lots of threads, but few actually running at any one
n Illusion: sequential execution, infinite processing power time – most waiting around for user to type in a window or for a
network packet to arrive

n Every major OS built since 1985 has provided threads n Might have 90 threads, but just a few on the ready queue
n Mach, OS/2, NT, Solaris, OSF
n Makes it a lot easier to write concurrent programs: web servers, n Result: system needs an extra 1MB of memory, consumed by waiting
threads. 1MB cost $200 in 1988
databases, embedded systems

n Did OS/2 run Excel or Word better? Ok, it gave you the ability to keep
n Does this mean that we should all go out and use threads? working when you use the printer, but is that worth $200?

n Are we making life easier for the OS developer or the end-user?

Performance Issues
n Consider parallel programs: for example, matrix multiplication:

for (i=0; i<n; i++)

for (j=0; j<n; j++)
for (k=0; k<n; k++)
C[i][j] += A[i][k] * B[j][k];

n Parallelization strategy: create a thread for every iteration of inner

loop, use a lock to protect access to elements in C

n Would work, but very inefficient:

n a few hundred instructions to create a thread
n about ten or so instructions to lock
n whereas each iteration might have only ten instructions in the first place!

n Threads are a nice abstraction, but aren’t cheap!