Monitors: overview
Overview of Presentation
encapsulation and appropriate abstraction
Monitors and Condition Variables
–
how they are an improvement over semaphores
The "Dining Philosophers" Problem
Overview of real synchronization mechanisms
–
exclusion requirements depend on object and methods
–
implementation should be encapsulated in object
–
clients shouldn't need to know the exclusion rules
a monitor is not merely a lock
–
kernel vs. user-mode synchronization
–
it is an object class, with instances, state, and methods
–
UNIX and NT exclusion and synchronization
–
all operations on object state protected by a semaphore
Interprocess Communication
–
Attributes of communications mechanisms
–
Overview of common IPC mechanisms
Advanced Synchronization Mechanisms
monitors have some very nice properties
5/13/03 - 1
–
easy to use for clients, hides unnecessary details
–
high confidence of adequate protection
Advanced Synchronization Mechanisms
5/13/03 - 2
Monitors: implementation
monitor generic {
semaphore mutex = 1;
... other private data ...
Monitors: use
// protects all methods in class generic
// public external entry points ... all get the mutex before any computation
public: generic_1(parms) { p(&mutex); _generic_1(parms); v(&mutex); }
generic_2(parms) {p(&mutex); _generic_2(parms); v(&mutex); }
// real implementations ... intra-monitor calls uses these directly
_generic_1( parms ) {
// real implementation of 1st method
...
}
_generic_2( parms ) {
// real implementation of 2nd method
...
}
}
Advanced Synchronization Mechanisms
5/13/03 - 3
monitor sharedBalance {
int balance;
public:
credit(int amount ) { balance = balance + amount; }
debit(int amount) { balance = balance - amount; }
}
// the automatic class locking serializes calls to credit and debit
// so that multiple threads cannot possibly interfere with one another
Advanced Synchronization Mechanisms
5/13/03 - 4
Monitors: simplicity vs. performance
(nested monitors – simpler isn't safer)
consider two monitors:
monitor locking is very conservative
–
lock the entire class (not merely a specific object)
–
lock for entire duration of any method invocations
–
QUEUE with methods: enqueue, dequeue
–
ADAPTOR with methods: process, receive
where ADAPTORs are implemented with QUEUEs
this can create performance problems
possible static deadlocks:
–
they eliminate conflicts by eliminating parallelism
–
QUEUE.enqueue adds entry, calls ADAPTOR.process
–
if a thread blocks in a monitor a convoy can form
–
ADAPTOR.process calls QUEUE.dequeue
There Ain't No Such Thing As A Free Lunch
–
fine-grained locking is difficult and error prone
–
coarse-grained locking creates bottle-necks
Advanced Synchronization Mechanisms
possible dynamic deadlocks:
5/13/03 - 5
–
thread 1 calls QUEUE.enque, calls ADAPTOR.process
–
thread 2 calls ADAPTOR.receive, calls QUEUE.enqueue
Advanced Synchronization Mechanisms
5/13/03 - 6
Condition Variables
nested monitors – example
separate the exclusion and waiting mechanisms
thread 2
thread 1
monitor: queue
monitor: adaptor
enqueue
receive
dequeue
process
mutual exclusion – monitor semaphores
–
prevent multiple threads from executing in monitor
–
threads blocked on condition vars aren't executing
completion awaiting – condition variables
–
two supported operations: wait and signal
–
release monitor semaphore prior to waiting
(can only be done at a safe point in computation)
–
reacquire monitor semaphore after signaled
safer and more powerful than semaphores alone
Advanced Synchronization Mechanisms
5/13/03 - 7
Advanced Synchronization Mechanisms
5/13/03 - 8
Monitor synchronization philosophy
monitor semaphore doesn't convey object ownership
–
it only controls critical sections for object operations
–
provides mutual exclusion for all operations
–
all data structures are protected by monitor semaphore
–
enables complex tests and operations to be atomic
condition variables are the opposite of locking
–
normally we seize a lock during critical sections
–
w/condition variables we unlock during safe sections ...
(and perhaps safe sections are easier to recognize)
5/13/03 - 9
The Dining Philosophers Problem
Five philosophers
five plates of pasta
five forks
is the classical illustration of deadlocking
it was created to illustrate deadlock problems
–
other variables must represent resource state
Advanced Synchronization Mechanisms
The Dining Philosophers Problem
they eat whenever
they choose to
it cannot be solved with semaphores
it is a very artificial problem
–
it was carefully designed to cause deadlocks
–
changing the problem would eliminate deadlocks
–
but then it couldn't be used to illustrate deadlocks
in the next lecture
–
we'll explore what makes situations deadlock-prone
Advanced Synchronization Mechanisms
5/13/03 - 10
Dining Philosophers w/semaphores
five semaphores, one per fork
when hungry, philosopher needs two forks
–
first P the left fork, then P the right fork
if all try to eat simultaneously, they deadlock
semaphores alone cannot solve this problem
one requires two
forks to eat pasta,
but must take them
one at a time
Advanced Synchronization Mechanisms
they will not
negotiate with
one-another
5/13/03 - 11
–
there is no way to look at semaphore count
–
one must hold the first fork and then P for second
–
if second fork is already taken, he will block
–
while blocked, he cannot free fork he already has
Advanced Synchronization Mechanisms
5/13/03 - 12
Dining Philosophers w/monitors
monitor semaphore does not control a particular fork
–
rather it controls the taking/returning of forks
–
only one philosopher at a time may take/return forks
a condition variable describes each pair of forks
–
if philosopher cannot obtain both, wait on the pair
–
wait operation blocks till both forks are free
–
when a fork is put down, see if pair should be signaled
–
signal operation awakens blocked philosopher
philosophers hold no forks while waiting
–
Dining Philosophers: solution
#define N 5
// # of philosophers
public:
enum status {eating, hungry, thinking};
// philo[i] is hungry, get his forks
monitor dining_philosophers {
pickUpForks( int i ) {
status state[N]; // state of each philo
state[i] = hungry;
condition self[N]; // condition var or forks
test(i);
// monitor protects operations on state/self
if (state[i] != eating) self[i].wait;
}
// see if we should give forks to philo[i]
// philo[i] is through eating, return his forks
test( int i ) {
putDownForks( int i ) {
if ((state[(i-1)%N] != eating) &&
state[i] = thinking;
(state[i] == hungry) &&
test((i-1) %N );
(state[(i+1)%N] != eating)) {
test((i+1) %N );
state[i] = eating;
};
self[i].signal;
diningPhilsophers() { // initialization
}
for( int i=0; i < N; i++ )
}
state[i] = thinking;
}
if noone blocks holding resources, there are no deadlocks
Advanced Synchronization Mechanisms
5/13/03 - 13
encapsulating synchronization behavior is right idea
state
T
T
T
T
T
–
object implementation should be responsible for object integrity
–
real synchronization behavior often spans multiple operations
monitors are not really a complete solution
self
1
2
3
4
5
5/13/03 - 14
Monitors: why have they been ignored?
Dining Philosophers: Solution
1
2
3
4
5
Advanced Synchronization Mechanisms
0
0
0
0
0
–
they don't relieve client of need for deadlock avoidance
–
signal or crash within monitor compromises resource
–
fork within monitor would have two threads in critical section
monitors are simple, but not high-performance
P2pick
P4pick P3pick P4put
Advanced Synchronization Mechanisms
P2put
5/13/03 - 15
–
artificially extended critical sections create coarse grained locking
–
unconditional and unlimited waits for all operations
–
condition variables don't deal with preemption and true parallelism
Advanced Synchronization Mechanisms
5/13/03 - 16
Monitors – wrap-up
user-mode synchronization operations
monitors are not used in real Operating Systems
–
–
but their key lessons are used everywhere
encapsulating object synchronization behavior
–
are often implicit
are often associated with other system objects
–
object implementations ensure object integrity
protecting critical sections vs. managing objects
e.g. open or read block until the operation completes
files, processes, messages, events
are usually general high level operations
–
critical sections are very tricky, and require locks
–
hide nasty details (like interrupts and SMP) from the caller
–
given mutual exclusion, object management is easy
–
have relatively simple behavior, little burden on caller
decoupling exclusion and completion awaiting
–
combining them yields crude tools, and deadlocks
Advanced Synchronization Mechanisms
5/13/03 - 17
are usually implemented via system calls into the OS
–
because they can affect scheduling and other processes
Advanced Synchronization Mechanisms
kernel-mode synchronization
UNIX: exclusion mechanisms
is almost always explicit
–
synchronization objects are fundamental to the OS
tends to have many options and flavors
–
shared vs. exclusive, interruptable, SMP susceptable, ...
–
may impose complex requirements on callers
implemented in a few machine language instructions
–
atomic instructions, interrupt disables, occasional spins
designed for high performance
–
minimal overhead for high frequency use
–
minimize contention in the face of massive parallelism
Advanced Synchronization Mechanisms
5/13/03 - 18
5/13/03 - 19
semaphores
–
sem_open, sem_close, sem_post, sem_wait
exclusive access file opens
advisory file locking (flock)
–
shared/exclusive, blocking/non-blocking
enforced record locking (lockf)
–
locks a contiguous region of a file
–
lock/unlock/test, blocking/non-blocking
all blocks can be aborted by a timer
Advanced Synchronization Mechanisms
5/13/03 - 20
NT: exclusion and synchronization
UNIX: asynchronous completions
most completions are associated with open files
–
normal files and devices
–
network or inter-process communication ports
–
poll if a logical channel is ready or would block
select the first of n channels to become ready
sleep for a specified interval of time
–
–
CreateEvent, Set, Reset, Pulse, Wait (for one/multiple)
Mutexes ... exactly one at a time
Create, Release, Wait (for one/multiple)
Critical Sections ... mutexes within a process
a signal will interrupt a block for any of these
5/13/03 - 21
–
we've talked about two parts of synchronization
–
mutual exclusion to protect critical sections
–
awaiting the availability of a requested resource (or the
completion of a requested operation)
we have talked about asynchronous event notification
traps and interrupts in the hardware, signals for software
these control the execution of threads and processes
the piece that is still missing is communication
Initialize, Enter, Leave, Delete
Advanced Synchronization Mechanisms
Inter Process Communication (IPC)
–
Create, Release, Wait (for one/multiple)
Events ... individual or group wakeup
–
wait for the termination of a child process
–
use for semaphores, events, and mutexes
Semaphores
open can specify blocking or non-blocking use
Advanced Synchronization Mechanisms
General WaitForOneObject, WaitForMultipleObjects
5/13/03 - 22
IPC through shared memory
sender/receiver must share some common memory
–
intra-process, all threads share same address space
–
inter-processes, OS must create/map shared segments
easy and efficient data management
–
data copying can be done with ordinary instructions
–
buffer pointers can be managed with atomic instructions
some applications may require OS exclusion mechanisms
notification done w/OS completion mechanisms
but it does have some security and integrity problems
the exchange of data between distinct processes
and the model does not work well over a network
Advanced Synchronization Mechanisms
5/13/03 - 23
Advanced Synchronization Mechanisms
5/13/03 - 24
IPC via message exchanges
Why implement messaging in the OS
to protect processes from one-another
communication through IPC channels
–
objects, implemented by the operating system
–
methods to set-up channels, send and receive messages
messages are exchanged between distinct processes
–
cross-address-space transfers require supervisor mode
to ensure message authenticity, privacy, and integrity
higher overhead than shared memory
–
–
system calls to copy from sender to OS, OS to receiver
messaging is more general
–
ensure every message properly identifies its sender
–
ensure no other process can see/change message
to ensure performance
–
IPC messages can be filtered and forwarded
–
messages represent natural transaction boundaries
messaging is more secure
–
IPC is the basis for a wide range of higher level services
–
data transfer and synchronization must be efficient
to encapsulate a lot of complexity
Advanced Synchronization Mechanisms
5/13/03 - 25
Advanced Synchronization Mechanisms
IPC: operations
IPC: messages vs streams
channel creation and destruction
Streams
write/send/put
–
insert data into the channel
read/receive/get
–
extract data from the channel
channel content query
–
–
a continuous stream of bytes
–
read or write few or many bytes at a time
–
write and read buffer sizes are unrelated
–
stream may contain app-specific record delimiters
messages/datagrams
how much data is currently in the channel
connection establishment and query
–
control connection of one channel end to another
–
who are end-points, what is status of connections
Advanced Synchronization Mechanisms
5/13/03 - 26
5/13/03 - 27
–
a sequence of distinct messages
–
each message has its own length (subject to limits)
–
message is typically read/written as a unit
–
delivery of a message is typically all-or-nothing
Advanced Synchronization Mechanisms
5/13/03 - 28
IPC: synchronous and asynchronous
IPC: communication fan-out
synchronous operations
point-to-point/unicast (1->1)
–
channel carries traffic from one sender to one receiver
multi-cast (1->N)
–
messages are sent to specified receivers or group
writes block until message sent/delivered/received
–
reads block until a new message is available
–
very easy for programmers
asynchronous operations
broadcast (1->N)
–
–
–
messages are sent to all receivers in a community
no confirmation of transmission/delivery/reception
requires auxiliary mechanism to learn of errors
publish/subscribe (N->M)
–
messages are distributed/filtered based on content
–
routing can be at sender, receiver, and in-between
Advanced Synchronization Mechanisms
5/13/03 - 29
–
in-band messages
often involves "wait for any of these" operation
Advanced Synchronization Mechanisms
messages delivered in same order as sent
–
message n+1 won't be seen till after message n
out-of-band messages
designed for connecting programs input/output
–
e.g. % diff file1.c file2.c | more
buffered inside OS
operations: read/write
use priority to “cut” ahead in the queue
priority must be honored on each link in the path
deliver them over a separate channel
a separate message channel, or perhaps a signal
Advanced Synchronization Mechanisms
IPC examples: UNIX pipes
can be inherited (stdin/stdout) or named/opened
messages that leap ahead of queued traffic
often used to announce errors or cancel requests
–
5/13/03 - 30
simple stream oriented communication
–
–
reads return promptly if no message available
requires auxiliary mechanism to learn of new messages
IPC: in-band vs out-of-band messages
–
writes return when system accepts message
–
reads and writes are synchronous
–
flow control achieved by blocking writer
contents may survive a reader close/reopen
5/13/03 - 31
Advanced Synchronization Mechanisms
5/13/03 - 32
IPC examples: mail boxes
IPC examples: UNIX sockets
more powerful than pipes
–
named message queues
can be bound to various protocols
tcp ... reliable stream, network protocol
udp ... unreliable datagrams, network protocol
–
associated with a particular receiving process
–
any process can send messages to any mailbox
additional semantics vary with implementations
unix ... named pipes
–
trusted identification of sending process
connect, listen, accept, broadcast, multicast
–
synchronous and asynchronous options
both stream and message semantics
–
confirmation of delivery (or receipt)
–
contents of queue may survive a kill and restart
–
more versatile connection options
–
read/write ... synchronous stream
–
send/recv ... synchronous datagrams
messages typically buffered in the OS
–
socket is destroyed when creator dies
Advanced Synchronization Mechanisms
5/13/03 - 33
for the next lecture
monitors and condition variables
but not section 10.5 (deadlock detection)
read it if you like, but I won't expect you to know it
–
–
avoidance and prevention techniques
–
other deadlock-like problems
–
detection and recovery strategies
Advanced Synchronization Mechanisms
why monitors, why condition variables, how they work
–
advantages of monitors over semaphores, problems
–
next lecture
deadlocks and how they occur
–
the dining philosopher problem
there will be a quiz on this material
–
5/13/03 - 34
key points
read chapter 10
–
some flow control is usually provided
Advanced Synchronization Mechanisms
how it illustrates deadlock, how to solve with monitors
inter process communication
5/13/03 - 35
–
shared memory vs. messages
–
stream vs. message
–
in-band vs. out-of-band, synchronous vs. asynchronous
–
unicast, multicast, pub/sub
Advanced Synchronization Mechanisms
5/13/03 - 36
IPC: reliable/confirmed delivery
IPC: flow-control
There are many reasons for a message not to be processed:
–
transient communications errors
–
receiver invalid, dead, or not responding
–
receiver got message but never processed it properly
queued messages consume system resources
–
many things can increase required buffer space
How hard/how long should we try to deliver it?
–
buffered in the OS until the receiver asks for them
–
try n times? try for n seconds? retry for ever?
sender faster than receiver, receiver is non-responsive
must be a way to limit required buffer space
When do we tell the sender "OK"?
–
queued locally? added to receivers input queue?
–
sender side: block sender or refuse message
–
receiver has read? receiver has acknowledged?
–
receiving side: stifle sender, flush old messages
–
this is usually handled by network protocols
Reliable and confirmed delivery don't come for free:
–
sender is delayed and buffers tied up until we say OK
– asynchronous acknowledgments
Advanced Synchronization Mechanisms
mechanisms to report stifle/flush to sender
are hard to use
5/13/03 - 37
Advanced Synchronization Mechanisms
5/13/03 - 38