Skip to main content
Link
Menu
Expand
(external link)
Document
Search
Copy
Copied
Search cs492-stevens
Lectures
Lecture 24 Template
24 - Concurrency II (2)
Outline
Recap
Monitors
Announcements
Reading:
Other Concurrency Primitives
Monitors
What we've covered so far:
A monitor is a synchronization primitive provided
(whole or in-part) by the programming language.
Essentially a special package/module/class
Readers-Writers Problem
1)
3)
2)
MOS 2.4.4 - 2.4.7
Midterms and PA 3 will be graded this week
We'll do midterm review after grades released
PA 4 instructions released
Approaches
Race Conditions
Critical Sections
Interrupt Disable
Lock Variables
Strict Alternation
Peterson's Solution
Busy-Waiting Solutions
Sleeping Solutions
Sleep & Wakeup
Semaphores
Mutexes
Monitors
-
-
-
-
Shared instance variables/fields
Condition Variables
Compiler keeps a hidden mutex lock that all
monitor procedures must acquire before executing.
Condition variables are used to manage sleeping
processes.
Calling process must
be holding the
relevant mutex before
doing condition
variable operations.
Processes invoke
scheduler on
wait/signal.
Mutually exclusive functions/procedures/methods
Single process/thread
allowed to call monitor
procedures
Monitor variables are
always private
All critical sections
encapsulated in monitor
procedures
Reduce complexity of writing correct solutions
by localizing related critical sections and shared
variables
Compiler implements mutual exclusion for critical
sections
>
>
>
monitor example
integer i
condition c
procedure producer()
...
end
procedure consumer()
...
end
end monitor
Operations:
(like down)
(like up)
wait(cond)
signal(cond)
-
-
-
-
-
add process to condition's wait queue
process releases monitor mutex and blocks
move to ready queue when woken up
wake up a blocked process from the queue
current process yields (release monitor mutex)
also see wikipedia: Monitors (synchronization)
Blocking Condition Variables
Monitor with Condition Variables
Note the differences:
Programmer is responsible for identifying condition
variables.
Alas, they aren't perfect for all situations.
Consider a situation where we have many reader
and writer processes sharing a data structure.
Using mutual exclusion with monitors, only one
process can access the structure at a time.
Finding a solution that allows multiple simultaneous
readers while ensuring mutually exclusive writers is
called the Readers-Writers problem.
Then, there are 3 variants to consider:
Readers do not modify the structure, so
simultaneous read-only access does not cause
race conditions.
We can get performance improvements by observing:
Writers modify data, so no other reader or
writer may run when a process has write access.
reader processes only read from the structure
accessing the structure becomes a bottleneck
and limits performance
writer processes modify the structure
Using monitors where applicable makes concurrent
code easier to reason about.
Instead of 2 semaphores tracking buffer state,
only need to maintain count variable, use
condition variable to signal on conditions.
No mutex on the buffer, since the monitor
guarantees mutual exclusion.
Same pseudocode will extend to arbitrary
number of producers and consumers.
monitor ProdCons
condition full, empty
integer count
buffer buf
procedure insert(item)
if count == N then wait(full)
buf.insert(item)
count = count + 1
if count == 1 then signal(empty)
end
procedure remove()
if count == 0 then wait(empty)
item = buf.remove()
count = count - 1
if count == N - 1 then signal(full)
return item
end
end monitor
procedure producer
begin
while true do
item = produce_item()
ProdCons.insert(item)
end
end
procedure consumer
begin
while true do
item = ProdCons.remove()
consume(item)
end
end
-
-
-
Java Example:
Readers-Writers Problem
Other Concurrency Primitives
Multiple Reader, Single Writer (MRSW) Locks
-
-
-
-
-
Main Constraint:
Reader's Preference
Reader's Preference Solution
Writer's Preference Solution
No Starvation
Writer's Preference
No Starvation
No thread may access a shared
resource if another thread is
writing to it.
No reader shall be kept waiting if the shared
data is currently open for reading.
Many readers can read at once, but writers
are potentially starved.
Many readers can read at once, but only if
there are no writers.
Writers have priority, and readers can starve.
Many potential solutions that optimize differently.
Solutions to readers-writers problem have been
implemented as "Read-Write Locks"
bound number of readers served when a writer
is present
use a priority queue
conditionally switch between reader's preference
and writer's preference
other ideas?
No writer shall be kept waiting longer than
absolutely necessary.
No reader or writer shall be allowed to starve.
1.
2.
3.
Courtois, Heymans, and Parnas. "Concurrent control with "readers" and "writers"." 1971
w1
critical section
critical section
w3
w3
w2
w2
r8
r8
r7
r7
r6
r6
r5
r5
-
-
-
-
Linux implements these as
Linux also has a number of other types of locks:
Acquired differently for readers and writers:
rwlock_t
read_lock
read_trylock
read_unlock
write_lock
write_trylock
write_unlock
-
-
-
-
-
-
-
-
Sleeping locks
Futex (Fast Userspace Mutex)
Read-copy-update (RCU)
Synchronization Barrier
Lockless algorithms
Message passing
(different from Memory Barrier)
CPU local locks (single core only)
Spinlocks
see kernel.org on "locking"