Skip to main content
Link
Menu
Expand
(external link)
Document
Search
Copy
Copied
Search cs492-stevens
Lectures
Lecture 19 Template
19 - Concurrency (2)
Outline
Race Conditions
Critical Sections
Mutual Exclusion
Mechanisms for Mutual Exclusion
Disabling Interrupts
Lock Variables
Announcements
Reading:
Race Conditions
Critical Sections
Mutual Exclusion
Disabling Interrupts
Any time storage is shared between processes,
there is potential for error.
2 friends are trying to wire you some money at
the same time.
Checking the last transaction in an opaque queue
Producer-Consumer Problem
a.k.a. Bounded Buffer Problem
Given:
Producers and consumers share the buffer
You send duplicate requests to withdraw money.
Race Conditions are situations where:
Common types of race conditions:
Lock Variables
PA 3 test script has been posted.
It's a Python script, so you may need to install
Python on your VM if you don't have it (hopefully
it's not too large)
1)
2)
3)
a)
b)
MOS 2.4.1 - 2.4.3
Examples
Data Races
2 or more processes rely on shared data
outcome depends on instruction interleaving
(non-deterministic)
Bad Interleavings
Error due to memory access by multiple
threads where at least one modifies data.
Error due to unfavorable execution order,
despite synchronized resources.
a fixed-size buffer B with N elements
uncoordinated reads/writes can cause race
conditions
programmer is generally responsible for
identifying critical regions
P producer processes
producers put data in the buffer
Consider single producer and consumer with the
following code:
Where's the bug?
increment and decrement are not necessarily a
single machine instruction:
How do we avoid race conditions?
A critical section is a region of program code
where shared data is accessed.
Avoid race conditions: prohibit multiple processes
from simultaneously executing critical section(s)
Make critical sections mutually exclusive by adding
entry and exit procedures:
Full criteria:
There are some additional scenarios to consider
when avoiding race conditions.
Disable all hardware interrupts before entering
critical section, the reenable them upon leaving.
Use a single shared variable (lock) between
processes for synchronization
Problem: now the race condition is on the lock!
Problems:
i.e. execution of critical sections should be
mutually exclusive.
A critical section is usually identified by desired
invariant properties that can be potentially broken
due to interleaving.
consumers remove data from the buffer
C consumer processes
>
>
>
>
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
1)
2)
3)
4)
-
-
-
-
-
int deposit(account, amount)
{
balance = get_balance(account);
balance += amount;
put_balance(account, balance);
return balance;
}
TX check_last(transactions)
{
TX last = pop_last(transactions);
TX last_copy = copy(last);
push_last(transactions, last);
return last_copy;
}
// shared global
volatile int balance;
int withdraw(account, amount)
{
if (amount <= balance) {
balance -= amount;
}
}
// shared global
volatile int balance;
int withdraw(account, amount)
{
if (amount <= balance) {
balance -= amount;
}
}
int deposit(account, amount)
{
balance = get_balance(account);
balance += amount;
put_balance(account, balance);
return balance;
}
void do_transaction(transactions, tx)
{
push_last(transactions, tx);
}
Process 1
Process 1
Process 1
Process 2
Process 2
Process 2
Read-Modify-Write & TOCTOU
Read-Modify-Write
Bad Interleaving (when push/pop atomic)
Unintended modification even if some synchronization present
Failure to correctly identify critical region
Producer
Consumer
Consumer
Consumer
Producer
Producer
N items
buffer B
// shared variables
const int size;
int count = 0;
item_t buffer[size];
count++
ld r1, count
add r1, 1
str r1, count
do {
work();
enter_critical();
do_critical();
exit_critical();
do_noncritical();
} while (cond);
while (1) {
while (lock != 0);
lock = 1;
do_critical();
lock = 0;
do_noncritical();
}
while (1) {
while (lock != 0);
lock = 1;
do_critical();
lock = 0;
do_noncritical();
}
while (1) {
while (lock != 0);
lock = 1;
do_critical();
lock = 0;
do_noncritical();
}
while (1) {
while (lock != 0);
lock = 1;
do_critical();
lock = 0;
do_noncritical();
}
Example:
void enter_critical()
{
interrupt_disable();
}
void enter_critical()
{
while (lock != 0);
lock = 1;
}
void exit_critical()
{
interrupt_enable();
}
void exit_critical()
{
lock = 0;
}
// producer
while (1) {
item_t A = produce();
while (count == size);
push(buffer, A);
count++;
}
// consumer
while (1) {
while (count == 0);
item_t A = pop(buffer);
count--;
consume(A);
}
(assume for now that push and pop are atomic)
r1 := count
r1 := count
r2 := count
r2 := count
r1 = r1 + 1
r1 = r1 + 1
r2 = r2 + 1
r2 = r2 + 1
count := r1
count := r1
count := r2
count := r2
producer
producer
consumer
consumer
ideal
actual
Some people draw a distinction.
Depends a bit on your level of abstraction.
more details
int deposit(account, amount)
{
balance = get_balance(account);
balance += amount;
put_balance(account, balance);
return balance;
}
Example:
reading/writing balance
invariant: conservation of money
(money is neither created nor destroyed)
enter_critical
disable interrupts
lock variables
sleep() and wakeup()
semaphores
mutexes
monitors
Prevents context switching (except syscall)
0 = no process in critical region
Can only be done in kernel mode
early Linux kernel versions
embedded systems
Doesn't usually work in multicore
Generally only used on single-core machines in kernel
User can otherwise misuse or abuse
interrupt disable instruction only works on current core.
other cores may still run critical section.
"Guarantee" only current process running
1 = some process in critical region
initialized to 0
strict alternation
Peterson's solution
test-and-set lock (TSL) instruction
Hardware:
Busy Wait:
Sleep & Wakeup:
Mutual Exclusion
No assumptions of CPU speed or # of cores
No Lockout (Progress)
No Starvation (Bounded Waiting)
Example:
exit_critical
Need mechanisms for
entry and exit
procedures to
enforce mutual
exclusion...
processes outside critical section should not block other
processes from entering their critical section
processes should not wait forever to enter critical section
proc A
proc B
A enters
critical
region
A leaves
critical
region
B tries
to enter
critical
region.
B enters
critical
region.
B leaves
critical
region.
B is blocked
time