Last on TTIT61
„ Processes are executing programs
„ Kernel manages them, their state, associated data (open
files, address translation tables, register values, etc.)
„ Threads are lightweight processes, i.e. they share data
segments, are cheaper to spawn and terminate
„ Scheduler selects next process to run among the ready
ones
„ Various scheduling algorithms and criteria to evaluate them
Synchronization
Alexandru Andrei
alean@ida.liu.se
phone: 013-322828, room: B 3D:439
A. Andrei, Process programming and operating systems, Synchronization
Lecture Plan
3
Need for Synchronization
„ Processes that do not interact with other processes (from
their functionality point of view) are independent
„ Processes that do interact are co-operating
A. Andrei, Process programming and operating systems, Synchronization
4
Need for Synchronization
„ The co-operating processes synchronize in some way
„ Synchronous: happening at the same time (Chronos:
Greek god of time)
„ E.g.:
„ Web server and browser (client) (and all applications in
the client-server paradigm)
„ Mail composer and spell checker
„ sort –nr +1 -2 < grades.txt | cut –f2 | uniq | head -10
† Takes a files where the grades are on the second
column, sorts it in descending order of the grades,
takes the second column, eliminates duplicates, and
prints the highest ten grades
A. Andrei, Process programming and operating systems, Synchronization
Outline
„ Need for synchronization
„ Synchronization mechanisms (1)
„ System calls: pause, select, waitpid
„ Message passing: blocking read/writes
„ Race conditions, critical regions, atomic operations, busywaiting, hardware support for their implementation
„ Synchronization mechanisms (2)
„ Semaphores
„ Monitors
„ Re-entrant code
„ Deadlock
„ Classical problems of synchronization
„ Readers/writers, bounded buffer, dining philosophers
1. What is an operating system? What are its functions?
Basics of computer architectures. (Part I of the textbook)
2. Processes, threads, schedulers (Part II , chap. III-V)
3. Synchronization & Deadlock (Part II, chap. VI, VII)
4. Primary memory management. (Part III, chap. VIII, IX)
5. File systems and secondary memory management (Part
IV, chap. X, XI, XII)
6. Security (Part V, chap. XIV)
A. Andrei, Process programming and operating systems, Synchronization
2
„ E.g.:
„ Web server pumps bytes down the connection after
getting a request. Browser reads served document after
the client starts sending it.
„ The spell checking is triggered by the appearance of
new text in the composer.
5
A. Andrei, Process programming and operating systems, Synchronization
6
1
One Producer/One Consumer
Producer1
Simple Solutions: Pause
Consumer.c:
...do something...
//wait for a signal
pause();
//continue after
//the signal was received
Consumer1
Producer.c:
...do something...
//now data was produced
kill(pid_of_consumer,
SIG_USR1);
//just told the consumer
„ Producer inserts data in the buffer
„ Consumer removes data from the buffer
A. Andrei, Process programming and operating systems, Synchronization
7
A. Andrei, Process programming and operating systems, Synchronization
More on Signals
int main() {
signal(SIGINT, sigproc);
signal(SIGUSR1, quitproc);
printf(”ctrl-c disabled use ctrl+\+\ to quit”);
for(;;); /* infinite loop */
}//end of main
void sigproc() {
signal(SIGINT, sigproc);
/* Some versions of UNIX will reset signal to
default after each call. So for portability reset
signal each time */
printf(”you have pressed ctrl+c but i wont die”);
}
void quitproc() {
printf(”now i will”);
exit(0); /* normal exit status */
}
A. Andrei, Process programming and operating systems, Synchronization
More on Signals (2)
[sasa@lap-154 ida]$ ./a.out
ctrl-c disabled use ctrl-\\
you have pressed ctrl-c but i'm not dying
you have pressed ctrl-c but i'm not dying
you have pressed ctrl-c but i'm not dying
now i'm dying
[sasa@lap-154 ida]$
[sasa@lap-154 ~]$ ps aux | grep a.out
sasa 12237 95.3 0.0 1500 296 pts/0 R+ 20:37 0:24 ./a.out
sasa 12247 0.0 0.1 3900 724 pts/1 S+ 20:38 0:00 grep a.out
[sasa@lap-154 ~]$ kill –SIGINT 12237 #it wont die
[sasa@lap-154 ~]$ kill –SIGUSR1 12237 #it will die
9
A. Andrei, Process programming and operating systems, Synchronization
Blocking Reads/Writes
„ The previous problems could also be solved with the
synchronization mechanism of blocking reads or writes
„ Blocking read:
„ The invoking process attempts to read something from
a descriptor (socket, pipe, file, message queue). If no
data is available for reading, the invoking process
blocks until data is available.
„ Blocking write:
„ The invoking process attempts to write a data item to a
descriptor. It blocks until a process consumes the data
item.
A. Andrei, Process programming and operating systems, Synchronization
8
10
Producer/Consumer
Producer1
Producer2
Consumer1
Producer3
„ Producers insert data in a file
„ Consumer reads data from the files
11
A. Andrei, Process programming and operating systems, Synchronization
12
2
Simple Solutions: Select
//client; has to read/write from/to 2 files
int fd1, fd2, max_fd;
fd_set readset;
fd1=open(”file1”, O_RDONLY); fd2=open(”file2”, O_WRONLY);
max_fd=max(fd1, fd2)+1;
do {
FD_ZERO(&readset);
FD_SET(, &readset);
result = select(max_fd, &readset, &writeset, NULL, NULL);
}while (1);
if (FD_ISSET(fd1, &readset)) {
/* fd1 has data available to be read */
result = read(fd1, some_buffer,100);
}
if (FD_ISSET(fd2, &writeset)) {
/* fd2 is available for writing */
result = write(fd2, ”blabla”, 6);
„ The select system call
„ The caller of select(fd, …) blocks until a specified
operation (read or write) is possible on the file descriptor
fd without blocking.
„ The mail composer could write everything the user
types to a pipe descriptor and the spell checker could
call select on the pipe descriptor.
„ Disadvantage: There must be a pipe, or socket, or file
shared between the caller of select and the processes
that makes the unblocking read or write possible.
„ man select in Solaris/Linux
A. Andrei, Process programming and operating systems, Synchronization
Non-blocking read (Multiplexing) Using select
13
A. Andrei, Process programming and operating systems, Synchronization
Unbounded Buffer
Read
Blocking
Not blocking
Outline
„ Need for synchronization
„ synchronization mechanisms
„ System calls: pause, select, waitpid
„ Message passing: blocking read/writes
„ Race conditions, critical regions, atomic operations, busywaiting, hardware support for their implementation
„ Synchronization mechanisms
„ Semaphores
„ Monitors
„ Re-entrant code
„ Deadlock
„ Classical problems of synchronization
„ Readers/writers, bounded buffer, dining philosophers
Write
X
X
How many elements would the buffer contain
if the writing was blocking?
A. Andrei, Process programming and operating systems, Synchronization
14
15
A. Andrei, Process programming and operating systems, Synchronization
Race Condition
„ We say that we have a race condition when, given that
several processes access the same data, the execution
outcome depends on the order in which the concurrent
processes accessed the data.
„ E.g.:
buffer[index] = processID;
++index;
16
Producer/Consumer
Producer1
Consumer1
Producer2
Consumer2
Producer3
Consumer3
„ Producers insert data in the buffer
„ Consumers remove data from the buffer
A. Andrei, Process programming and operating systems, Synchronization
17
A. Andrei, Process programming and operating systems, Synchronization
18
3
Producer/Consumer
Producer {
Consumer {
/*produce an item and put in
while (count == 0)
nextProduced */
; // do nothing
while (count == BUFFER_SIZE)
nextConsumed = buffer[out];
; // do nothing
out = (out + 1) % BUFFER_SIZE;
buffer [in] = nextProduced;
in = (in + 1) % BUFFER_SIZE;
count--;
count++;
//consume the item in nextConsumed
}
}
A. Andrei, Process programming and operating systems, Synchronization
19
Critical Sections
„ A critical section is a section of code that no process may
execute while another process executes it.
„ The execution of critical sections by processes is mutually
exclusive in time
„ The critical section problem is to design a protocol to
ensure the mutual exclusive execution
A. Andrei, Process programming and operating systems, Synchronization
Critical-Section Requirements
Two-Process Solution (1)
turn={i or j} is a global variable designating the process
(Pi or Pj) that may enter the critical section
Mutual Exclusion - If process Pi is executing in its critical
section, then no other processes can be executing in their
critical sections
2. Progress - If no process is executing in its critical section
and there exist some processes that wish to enter their
critical section, then the selection of the processes that will
enter the critical section next cannot be postponed
indefinitely
3. Bounded Waiting - A bound must exist on the number of
times that other processes are allowed to enter their critical
sections after a process has made a request to enter its
critical section and before that request is granted
y Assume that each process executes at a nonzero speed
y No assumption concerning relative speed of the N
processes
1.
A. Andrei, Process programming and operating systems, Synchronization
Pi
do {
while (turn != i) no-op;
critical section
turn = j;
remainder
} while (true);
21
Pj
do {
2 flag[j] = true;
4 while (flag[i]) no-op;
critical section
flag[j] = false;
remainder
} while (true);
A. Andrei, Process programming and operating systems, Synchronization
22
Two-Process Solution (3)
Pi
Pj
do {
do {
flag[i] = true;
flag[j] = true;
turn = j;
turn = i;
while (flag[j] && turn == j) no-op;
while (flag[i] && turn == i) no-op;
critical section
critical section
flag[j] = false;
flag[i] = false;
remainder
remainder
} while (true);
} while (true);
ƒDeadlock!
A. Andrei, Process programming and operating systems, Synchronization
Pj
do {
while (turn != j) no-op;
critical section
turn = i;
remainder
} while (true);
„Progress?
Two-Process Solution (2)
Pi
do {
1 flag[i] = true;
3 while (flag[j]) no-op;
critical section
flag[i] = false;
remainder
} while (true);
20
„ Works? YES !
23
A. Andrei, Process programming and operating systems, Synchronization
24
4
Multiple-Process Solution
do {
choosing[i] = true;
number[i] = max(number[0], …, number[n – 1]) + 1;
choosing[i] = false;
for (j = 0; j < n; j++) {
while (choosing[j]) no-op;
while (number[j] != 0 && (number[j], j) < (number[i], i))
no-op;
}
critical section
number[i] = 0;
remainder
} while (true);
A. Andrei, Process programming and operating systems, Synchronization
„ All algorithms on previous slides contained
while (condition) do nothing;
„ The process is marked as ready, and whenever running, it
just wastes CPU time (and money, where one buys CPU
time)
„ The process is said to be busy waiting
25
Busy Waiting
27
Hardware Support: Test and Set
boolean TestAndSet(boolean *target) {
boolean rv = *target;
*target = true;
return rv;
}
„ It runs atomically, i.e. as an uninterruptible unit.
„ lock set to false means it is free
do {
while (TestAndSet(lock)) no-op;
critical section
lock = false;
remainder
} while (true);
A. Andrei, Process programming and operating systems, Synchronization
A. Andrei, Process programming and operating systems, Synchronization
26
Hardware Support: Interrupts
„ Disabling interrupts when entering the critical section.
„ Not efficient for multi-processor systems
„ If the critical section is long, the system is not
responsive and/or it may lose events
„ It would be better if the waiting is supported by the OS. The
process marks itself as waiting, is not anymore ready, and
waits for a notification from the OS when it may wake up
and become ready again.
„ No CPU cycles wasted, additional complexity in the OS,
additional context switches.
„ If we know that a process would wait for a very short time,
busy waiting loops could be preferred to OS support.
A. Andrei, Process programming and operating systems, Synchronization
Busy Waiting
A. Andrei, Process programming and operating systems, Synchronization
28
Hardware Support: Swap
„ key[i] is local to process i; lock is global
do {
key[i] = true;
while (key[i] == true)
swap(lock, key[i]);
critical section
lock = false
remainder
} while (true);
„ Are these two solutions, TestAndSet-based and Swapbased, two-process solutions or multiple-process
solutions?
29
A. Andrei, Process programming and operating systems, Synchronization
30
5
Hardware Support: Swap
„ Need for synchronization
„ synchronization mechanisms
„ System calls: pause, select, waitpid
„ Message passing: blocking read/writes
„ Race conditions, critical regions, atomic operations, busywaiting, hardware support for their implementation
„ Synchronization mechanisms
„ Semaphores
„ Monitors
„ Re-entrant code
„ Deadlock
„ Classical problems of synchronization
„ Readers/writers, bounded buffer, dining philosophers
„ Are these two solutions, TestAndSet-based and Swapbased, two-process solutions or multiple-process
solutions?
„ Single processor or multiprocessor ?
A. Andrei, Process programming and operating systems, Synchronization
31
Semaphores
„ Semaphores:
„ Synchronization tool introduced by Dijkstra with the
following two operations:
† P() (Dutch: probeeren = to test)
– while (S≤0) no-op; --S;
† V() (Dutch: verhogen = to increment)
– ++S;
„ No modification of S is allowed to be performed by a
process while another process operates on S.
„ Testing and decrementing of S in P has to be done
without interruption by another process.
A. Andrei, Process programming and operating systems, Synchronization
Outline
A. Andrei, Process programming and operating systems, Synchronization
Critical Sections with Semaphores
do {
sem.P();
critical section
sem.V();
remainder
} while (true)
„ Multi-process or two-process solution?
„ The semaphore can be binary or counting
„ To do busy waiting or not to do busy waiting
33
A. Andrei, Process programming and operating systems, Synchronization
„ Reader:
sem.P();
data item = read(fd);
We assume an unbounded buffer associated to the descriptor fd
A. Andrei, Process programming and operating systems, Synchronization
35
34
P()
Non-Blocking Write, Blocking Read with Sem.
„ Writer:
write(fd, data item);
sem.V();
32
void
Semaphore::P() {
IntStatus oldLevel = interrupt->SetLevel(IntOff); // disable interrupts
while (value == 0) {
// semaphore not available
currentThread->Sleep(); //go to sleep, avoid busy-waiting
}
value--; // semaphore available, consume its value
(void) interrupt->SetLevel(oldLevel);
// restore interrupts
}
A. Andrei, Process programming and operating systems, Synchronization
36
6
V()
„ Is a high-level synchronization construct
„ Contains a set of programmer-defined operators
„ Represented by a set of variables (defining the state) and a
set of procedures
void
Semaphore::V() {
IntStatus oldLevel = interrupt->SetLevel(IntOff);
if (thread != NULL)
// make thread ready, consuming the V immediately
scheduler->ReadyToRun(waiting_thread);
value++;
(void) interrupt->SetLevel(oldLevel);
}
A. Andrei, Process programming and operating systems, Synchronization
Monitors
monitor name {
shared variables declaration
procedure P1(…) {
}
procedure Pn(…) {
}
{ initialisation code}
}
37
38
„ Let S and Q be two semaphores initialized to 1
P1
P0
S.P();
Q.P();
.
.
.
Q.V();
S.V();
Q.P();
S.P();
.
.
.
S.V();
Q.V();
„ Deadlock – two or more processes are waiting indefinitely for an event
that can be caused by only one of the waiting processes
„ Starvation – indefinite blocking. A process may never be removed
from the semaphore queue in which it is suspended.
Thread 2: A q;
q.Y()
A. Andrei, Process programming and operating systems, Synchronization
// array construction
Deadlock and Starvation
Class A {
void synchronized X();
void synchronized Y();
....
}
Thread 1: A p;
p.X();
// get
A. Andrei, Process programming and operating systems, Synchronization
Java Monitors
„ The synchronized keyword used for methods inside a class
// the array of the BB
// put
39
A. Andrei, Process programming and operating systems, Synchronization
Condition Variables
40
Conditions
„ Conditions:
„ Wait:
† Invoking process appends itself to the queue
corresponding to the condition
† It releases the monitor/lock/semaphore
† It blocks (thread/process is moved to BLOCKED)
† After it is woken up, it re-acquires the monitor
„ Signal
† A blocked process from the queue of processes that
wait on the condition is woken up
„ Acquire a semaphore only when you are sure it can
be used
„ Condition variables:
„ Semaphore.P() -> Condition.Wait(semaphore)
„ Semaphore.V() -> Condition.Signal()
„ Order?
A. Andrei, Process programming and operating systems, Synchronization
41
A. Andrei, Process programming and operating systems, Synchronization
42
7
Solaris Synchronization
„ Implements a variety of locks to support multitasking,
multithreading (including real-time threads), and
multiprocessing
„ Uses adaptive mutexes for efficiency when protecting data
from short code segments
„ Uses condition variables and readers-writers locks when
longer sections of code need access to data
„ Uses turnstiles to order the list of threads waiting to acquire
either an adaptive mutex or reader-writer lock
A. Andrei, Process programming and operating systems, Synchronization
Windows XP Synchronization
„ Uses interrupt masks to protect access to global resources
on uniprocessor systems
„ Uses spinlocks on multiprocessor systems
„ Also provides dispatcher objects which may act as either
mutexes and semaphores
„ Dispatcher objects may also provide events
„ An event acts much like a condition variable
43
A. Andrei, Process programming and operating systems, Synchronization
Linux Synchronization
Outline
„ Need for synchronization
„ synchronization mechanisms
„ System calls: pause, select, waitpid
„ Message passing: blocking read/writes
„ Race conditions, critical regions, atomic operations, busywaiting, hardware support for their implementation
„ synchronization mechanisms
„ Semaphores
„ Monitors
„ Re-entrant code
„ Deadlock
„ Classical problems of synchronization
„ Readers/writers, bounded buffer, dining philosophers
„ Linux:
„ disables interrupts to implement short critical sections
„ Linux provides:
„ semaphores
„ spin locks
A. Andrei, Process programming and operating systems, Synchronization
44
45
Re-Entrant Code
„ A section of code that may be executed by a process before
another process leaves it
A. Andrei, Process programming and operating systems, Synchronization
46
Re-Entrant Code
„ The problem with the previous code is that both processes
share the kernel_buffer array.
„ E.g.:
char kernel_buffer[BUF_MAX];
void user_to_kernel(int virtualAddr, char kernel_buf[]) {
int physicalAddr, i = 0;
do {
physicalAddr = translate(virtualAddr);
kernel_buf [i++] = c = memory[physicalAddr];
} while (c != ‘\0’);
}
„ Do not use global variables when writing re-entrant code
„ If you have to use them, then protect them with locks. The
protected accesses will not be re-entrant any more.
user_to_kernel(1000, kernel_buffer) || user_to_kernel(2000, kernel_buffer)
A. Andrei, Process programming and operating systems, Synchronization
47
A. Andrei, Process programming and operating systems, Synchronization
48
8
Outline
„ Need for synchronization
„ synchronization mechanisms
„ System calls: pause, select, waitpid
„ Message passing: blocking read/writes
„ Race conditions, critical regions, atomic operations, busywaiting, hardware support for their implementation
„ synchronization mechanisms
„ Semaphores
„ Monitors
„ Re-entrant code
„ Deadlock
„ Classical problems of synchronization
„ Readers/writers, bounded buffer, dining philosophers
A. Andrei, Process programming and operating systems, Synchronization
Bridge Crossing Example
„ Kansas law:
”When two trains approach each other at a crossing,
both shall come to a full stop and neither shall start
up again until the other one has gone”
49
A. Andrei, Process programming and operating systems, Synchronization
Deadlock
P0
A
P0
P1
B
50
Conditions for Deadlock
P1
wait (A);
wait(B);
wait (B);
wait(A);
ƒ Mutual exclusion: At least one resource cannot be shared
ƒ Hold and wait: A process must be holding at least one
resource and waiting to acquire additional resources, held
by other processes
ƒ No preemption: Resources are released only voluntarily
ƒ Circular wait: P0 must wait on a resource held by P1, which
in turn waits on a resource held by P2, … held by Pn-1,
which in turn waits on a resource held by P0
„ Process P0 blocks if resource B is unavailable
„ Resource B may never become available because process
P1 holds it and never releases it
„ Process P1 may never release it because in its turn, it waits
for a different resource, A, that could be held by process P0
„ Processes P0 and P1 deadlocked
A. Andrei, Process programming and operating systems, Synchronization
51
A. Andrei, Process programming and operating systems, Synchronization
System Model
52
Resource-Allocation Graph
„ Process
„ Resource types R1, R2, . . ., Rm
CPU cycles, memory space, I/O devices
„ Each resource type Ri has Wi instances.
„ Each process utilizes a resource as follows:
„ request
„ use
„ release
„ Resource Type with 4 instances
„ Pi requests instance of Rj
Pi
Rj
„ Pi is holding an instance of Rj
Pi
Rj
A. Andrei, Process programming and operating systems, Synchronization
53
A. Andrei, Process programming and operating systems, Synchronization
54
9
Resource Allocation Graph
R1
P1
R2
„ Process → Resource edge
indicates resource request
„ Resource → Process edge
indicates that the resource is
held by the process
R3
P2
P2
R1
P3
P3
R4
Resource Allocation Graph
P1
„ Existence of cycles is a
necessary condition for the
existence of deadlocks
„ Also sufficient if there exists
only one instance of each
resource
A. Andrei, Process programming and operating systems, Synchronization
„ We have a cycle, but no
deadlock
„ When P4 releases an
instance of R2, P3 may
take it
R2
P4
55
A. Andrei, Process programming and operating systems, Synchronization
Handling Deadlocks
Outline
„ Need for synchronization
„ synchronization mechanisms
„ System calls: pause, select, waitpid
„ Message passing: blocking read/writes
„ Race conditions, critical regions, atomic operations, busywaiting, hardware support for their implementation
„ synchronization mechanisms
„ Semaphores
„ Monitors
„ Re-entrant code
„ Deadlock
„ Classical problems of synchronization
„ Readers/writers, bounded buffer, dining philosophers
„ Deadlock avoidance
„ Deadlock detection and recovery
„ Ignore the problem
A. Andrei, Process programming and operating systems, Synchronization
56
57
Classical Problems: Dining Philosophers
A. Andrei, Process programming and operating systems, Synchronization
58
Readers/Writers Problem
„ There exists a shared resource
„ Processes that do not change it upon an access are readers
„ All the other are writers
„ First readers/writers problem:
„ No reader will be kept waiting unless a writer has already
obtained writing permission (Read accesses are not
blocked if a writer manifested interest in writing)
„ Dining philosophers:
„ They may eat only when they have both forks
„ They cannot get both forks in one move
„ Implement a resource (fork) access protocol for
philosophers such that they do not starve
A. Andrei, Process programming and operating systems, Synchronization
„ Second readers/writers problem:
„ Once a writer is ready, that writer performs its write as
soon as possible (Read accesses are blocked if a writer
manifested interest in writing)
59
A. Andrei, Process programming and operating systems, Synchronization
60
10
Readers/Writers Problem
Writer:
.
.
.
A. Andrei, Process programming and operating systems, Synchronization
61
„ Need for processes synchronization
„ Race condition, critical section, atomic operations, mutual
exclusion
„ Critical section access protocols
„ Busy waiting
„ Hardware support
„ Semaphores, monitors, conditions
„ Deadlocks
Writer:
sem_writers.P();
//WRITE
sem_writers.V();
A. Andrei, Process programming and operating systems, Synchronization
Summary
A. Andrei, Process programming and operating systems, Synchronization
Readers/Writers Problem
Reader:
sem_readers.P();
if (counter_readers==0)
sem_writers.P();
counter_readers++;
sem_readers.V();
//READ
sem_readers.P();
counter_readers--;
if (counter_readers==0)
sem_writers.V();
sem_readers.V();
int counter_readers;
Semaphore sem_readers;
Semaphore sem_writers;
Reader:
.
.
.
int counter_readers;
Semaphore sem_readers;
Semaphore sem_writers;
62
Reading Material
„ Silberschatz, 7th edition
„ Chapter 6: 6.1 – 6.8
„ Chapter 7: 7.1 – 7.4
63
A. Andrei, Process programming and operating systems, Synchronization
64
11