Skip to main content
Link
Menu
Expand
(external link)
Document
Search
Copy
Copied
Search cs492-stevens
Lectures
Lecture 20 Template
20 - Concurrency (4)
Outline
Summary
Lock Variables with Hardware
Strict Alternation
Peterson's Solution
Announcements
Reading:
Summary
We saw last time a first attempt at guarding the
critical section with software.
Mutual Exclusion
Lock Variables with Hardware
Strict Alternation
Peterson's Solution
Mid-semester feedback survey is out.
2 extra points on the midterm for 70% completion
(by section)
1)
2)
a)
b)
c)
MOS 2.4.1 - 2.4.3
void enter_critical()
{
while (lock != 0);
lock = 1;
}
void exit_critical()
{
lock = 0;
}
Problem: now the race condition is on the lock!
The lock variable uses busy-waiting to guard entry
to critical section.
This is also called a spinlock.
Wastes CPU time, so should only be used if
wait time is guaranteed to be very short.
TSL (Test-and-Set Lock) Instruction
TSL (Test-and-Set Lock) Instruction
XCHG Instruction (Compare and Swap)
Hardware Lock Variables
XCHG (Exchange/Swap) Instruction
copies current value at address to register
used to only lock memory bus
now requires modification to cache coherency
protocol
sets value at address to True (non-zero)
Lock variables require hardware support to avoid
race condition.
while (1) {
while (lock != 0);
lock = 1;
do_critical();
lock = 0;
do_noncritical();
}
while (1) {
while (turn != 0);
do_critical();
turn = 1;
do_noncritical();
}
while (1) {
flags[0] = TRUE;
turn = 1;
while(turn==1 && flags[1]);
do_critical();
flags[0] = FALSE;
do_noncritical();
}
while (1) {
flags[1] = TRUE;
turn = 0;
while(turn==0 && flags[0]);
do_critical();
flags[1] = FALSE;
do_noncritical();
}
while (1) {
while (turn != 0);
do_critical();
turn = 1;
do_noncritical();
}
while (1) {
enter_critical:
asm(TSL r1, lock);
asm(CMP r1, #0);
asm(JNE enter_critical);
do_critical();
exit_critical:
asm(MOV lock, #0);
do_noncritical();
}
while (1) {
enter_critical:
asm(TSL r1, lock);
asm(CMP r1, #0);
asm(JNE enter_critical);
do_critical();
exit_critical:
asm(MOV lock, #0);
do_noncritical();
}
while (1) {
while (lock != 0);
lock = 1;
do_critical();
lock = 0;
do_noncritical();
}
while (1) {
while (turn != 1);
do_critical();
turn = 0;
do_noncritical();
}
while (1) {
while (turn != 1);
do_critical();
turn = 2;
do_noncritical();
}
while (1) {
while (turn != 2);
do_critical();
turn = 0;
do_noncritical();
}
now both in critical section!
-
-
-
-
-
-
-
-
-
-
-
Generally 2 options:
Atomic read-modify-write. In a single step:
Alternative atomic read-modify-write:
More or less the same as TSL.
Multiple processes now look like:
Revisit our solution criteria:
if proc A runs first, TSL will set the lock to
TRUE set r1 to 0 (lock initialized to FALSE)
and proc A will be able to enter critical section
if proc B preempts proc A, the result of TSL
will have TRUE in r1, and proc B will continue
looping.
race condition is prevented no matter where
preemption occurs in the lock checking.
proc B can continue after proc A unsets lock
CPU designers implement atomicity in hardware
The entry and exit procedures become:
The entry and exit procedures:
(it's still a spinlock)
(again, still a spinlock)
TSL reg, mem_address
XCHG reg, lock_address
enter_critical:
TSL r1, lock_addr
CMP r1, #0
JNE enter_critical
exit_critical:
MOV lock_addr, #0
proc A
proc B
1)
2)
3)
4)
Mutual Exclusion
No assumptions of CPU speed or # of cores
Progress (No Lockout)
Bounded Waiting (No Starvation)
-
-
-
-
-
-
-
-
-
-
-
-
No race conditions
Simple
Requires hardware support (instruction set)
e.g. turn = 0 => process 0 can enter, etc.
"turn" indicates which process gets to enter
Analogy: processes race through waiting rooms.
"flags" indicates if a process wants to enter
e.g. process 0 before 1, 1 before 2, etc.
Example
Example: more processes
Idea: add a "flags" array to the "turn" variable
Gary L. Peterson. "Myths About the Mutual
Exclusion Problem". 1981.
Each process indicates it wants to enter its
critical section, then tries to give the other
process a turn first.
Processes busy wait while it is the other process's
turn and that process actually wants to use its
turn.
Peterson's algorithm was designed for 2
processes, but has been generalized to arbitrarily
many with a little hardware support.
Note: there are other correct algorithms under the
same assumption.
(e.g. Dekker's algorithm, Lamport's algorithm, ...)
Peterson's is correct under the assumption of a
sequential consistency memory model.
The basic form (2 processes):
proc 0
proc 0
proc 1
proc 1
proc 2
processes strictly alternate execution
Can we get mutual exclusion without hardware
support?
Idea: Use a single "turn" variable to indicate which
process is currently allowed to enter critical
Multicore scalability
Starvation is theoretically possible
Advantages:
Disadvantages:
Cache coherency hardware protocol becomes more complex with
more cores and cache levels
statistically unlikely, so works well enough in practice
(think geometric distribution)
Hurts performance if lock being used often
Not an unreasonable assumption these days
Swaps contents of register and memory address
Slightly more flexible since value can be chosen
-
-
enter_critical:
MOV r1, #1
XCHG r1, lock
CMP r1, #0
JNE enter_critical
exit_critical:
MOV lock, #0
Criteria:
1)
2)
3)
4)
Mutual Exclusion (No Race Condition)
No assumptions of CPU speed or # of cores
Progress (No Lockout)
Bounded Waiting (No Starvation)
process 0
process 1
Criteria:
1)
2)
3)
4)
Mutual Exclusion (No Race Condition)
No assumptions of CPU speed or # of cores
Progress (No Lockout)
Bounded Waiting (No Starvation)
See Filter Algorithm
-
-
-
-
-
-
-
-
No race conditions*
Satisfies all criteria*
Fully software algorithm*
*Thwarted by modern hardware
Generalization is non-trivial
Still a busy-waiting algorithm
Computation of multiple threads is identical to
interleaving in preserved order
Violated in many modern architectures.
(cache coherence, out-of-order execution)
Advantages:
Disadvantages:
And still ultimately dependent on some hardware support
Wasted CPU cycles...
Multicore cache coherency, out-of-order execution
Solution Criteria:
Busy Waiting Solutions:
Solutions to race conditions do not necessarily
solve the Priority Inversion Problem.
1)
2)
3)
4)
Mutual Exclusion (No Race Condition)
No assumptions of CPU speed or # of cores
Progress (No Lockout)
Bounded Waiting (No Starvation)
at most one process in critical section at a time
a process should not block other processes if it is not
attempting to enter its critical section.
a process must be guaranteed to enter its critical section within
a fixed time.
correctness independent of execution speed or number of cores
-
-
-
-
-
-
-
-
-
Correct solutions:
Software-only lock variables
Hardware-supported lock variables
Strict alternation
Peterson's solution*
Incorrect solutions:
Always waste time
lower priority process can block higher priority
one while in critical section
complicated, but usually resolved with temporary
priority elevation