Operating Systems Unit 3: – Concurrent execution mutual exclusion – Concurrent programming semaphore monitor Operating Systems

Operating Systems

Unit 3:– Concurrent execution

• mutual exclusion

– Concurrent programming

• semaphore• monitor

Operating Systems

COP 5994 - Operating Systems 2

Concurrent execution

• System has more than one thread/process

• either independent or in cooperation:– mostly independent– occasionally need to communicate or

synchronize


Communication/synchronization

• Threads may access resource simultaneously– resource can be put in inconsistent state

• Context switch can occur at anytime, such as before a thread finishes modifying value

• Solution: mutual exclusion– idea: serialized access – Only one thread allowed access at one time– Others must wait until resource is available

• Must be managed such that wait time not unreasonable


Critical section

• a Section of code– where shared resource is modified– only one thread can be in its critical

section– avoid infinite loops and blocking inside

• Provides mutual exclusion• Rest of code is safe to run

concurrently


Mutual Exclusion properties

Mutual ExclusionIf process is executing in its critical section, then no other processes can be executing in their critical sections

ProgressIf 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

Assume that each process executes at a nonzero speed No assumption concerning relative speed of the n processes

Bounded WaitingA limit 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


Mutual exclusion algorithm

• General structure of process Pi (vs. Pj)

do {entry protocolcritical sectionexit protocolremainder section

} while (true);


Dekker’s Algorithm

• Idea: processes share common variables to synchronize their actions: int turn;– denotes which process is favored to

enter its critical sectionboolean flag[2];– denotes whether process is ready to

enter its critical section


Dekker’s Algorithm: Process Pi

do {flag[i] = true;while (flag[j]) {

if (turn == j) {flag[i] = false;while ( turn == j ) ;flag[i] = true;

}}critical sectionturn = j;flag[i] = false;remainder section

} while(true);


Dekker’s Algorithm

• Guarantees mutual exclusion for 2 processes

• Uses notion of favored thread to resolve conflict over which thread should execute first

• Each thread temporarily yields to other thread

• Favored status alternates between threads


Peterson’s Algorithm

• Less complicated than Dekker’s Algorithm– Still uses busy waiting, favored threads– Requires fewer steps to perform

mutual exclusion primitives– Easier to demonstrate its correctness


Peterson’s Algorithm: Process Pi

do {flag[i] = true;turn = j;while (flag[j] and turn

== j) ;critical sectionflag[i] = false;remainder section

} while (true);


Lamport’s Bakery Algorithm

• N-Thread Mutual Exclusion– Creates a queue of waiting threads by

distributing numbered “tickets”– Each thread executes when its ticket’s

number is the lowest of all threads– Unlike Dekker’s and Peterson’s Algorithms,

the Bakery Algorithm works in multiprocessor systems and for n threads

– Relatively simple to understand due to its real-world analog


Bakery Algorithm

Critical section for n processes: • Before entering its critical section

process receives a number• Holder of the smallest number enters critical

section

• If processes Pi and Pj receive the same number, process with lower process id is served first

• The numbering scheme always generates numbers in increasing order of enumeration; i.e., 1,2,3,3,3,3,4,5...


Bakery Algorithm

• Shared databoolean choosing[n];int number[n];

Data structures are initialized to false and 0 respectively


Bakery Algorithm

do { choosing[i] = true;number[i] = max(number[0], number[1], …, number [n – 1])+1;choosing[i] = false;for (j = 0; j < n; j++) {

while (choosing[j]) ; while ((number[j] != 0) && (number[j],j) <

number[i],i)) ;}critical sectionnumber[i] = 0;remainder section

} while (true);


Mutual Exclusion via Hardware

• Disabling interrupts• Special instructions

– test and set– swap


Disabling Interrupts

• mask interrupts while in critical section– current thread cannot be preempted

• could result in deadlock– e.g.: thread does I/O block in critical

section

• works only on uniprocessor systems • used rarely


Test-and-Set Instruction

boolean testAndSet(var) • returns the value of var and sets var

to true

• atomic instruction• simplifies mutual exclusion algorithm• algorithm must use instruction

correctly



do {while

(testAndSet(lock)) ;critical sectionlock = false;remainder section

} while (true);


Swap Instruction

swap(a, b) • exchanges the values of a and b

atomically

• Similar in functionality to test-and-set– more common



do {myTurn = true;do {

swap(lock, myTurn);} while (myTurn) ;critical sectionlock = false;remainder section

} while (true);


Semaphore

• Software construct to enforce mutual exclusion

• Contains a protected variable:– accessed via wait and signal commands

P V

• binary semaphore: 0 or one• counting semaphore


Binary Semaphores

• only one thread allowed in critical section– Wait operation: P

• If no other thread in critical section: – thread enters critical section– Decrement protected variable (to 0 in this case)

• Otherwise place in waiting queue

– Signal operation: V• Indicate that thread has left its critical section• Increment protected variable (from 0 to 1)• A waiting thread (if there is one) may now enter



do {P(lock) ;critical sectionV(lock);remainder section

} while (true);


Synchronization with Semaphores

• Semaphores can be used to notify other threads that events have occurred– Producer-consumer relationship:

• Producer enters its critical section to produce value• Consumer is blocked until producer finishes• Consumer enters its critical section to read value• Producer cannot update value until it is consumed

– Semaphores offer a clear, easy-to-implement solution to this problem


Counting Semaphores

• Initialized with values greater than one• Can be used to control access to a pool

of identical resources– Decrement the semaphore’s counter when

taking resource from pool– Increment the semaphore’s counter when

returning it to pool– If no resources are available, thread is

blocked until a resource becomes available


Implementing Semaphores

• Application level– typically implemented by busy waiting– inefficient

• Kernel implementations• block waiting threads via locks• disable interrupts via masks

– must avoid poor performance and deadlock– hard to implement on multiprocessor

systems


Linux Synchronization Tools

• to protect kernel data structures: – spin lock

• reader/writer lock• seqlock

– kernel semaphore

• general thread synchronization– System V Semaphores


Linux Kernel Spin Locks

• Protects critical sections on SMP systems– Once acquired, all subsequent requests

to the spin lock cause busy waiting (spinning) until the lock is released

• Unnecessary in uniprocessor systems– code removed for speed


Linux Kernel Reader/Writer Locks

• optimize concurrency for read/write of kernel data– Allow multiple kernel control paths to hold a read

lock, but permit only one kernel control path to hold a write lock with no concurrent readers

– A kernel control path that holds a read lock on a critical section must release its read lock and acquire a write lock if it wishes to modify data

– An attempt to acquire a write lock succeeds only if there are no other readers or writers concurrently executing inside their critical sections.


Linux Kernel Seqlocks

• Seqlocks– Allow writers to access data immediately

without waiting for readers to release the lock

– Combines spinlock with a sequence counter– Requires readers to detect if a writer has

modified the value of the data protected by the seqlock by examining the value of the seqlock’s sequence counter

– Appropriate for interrupt handling


Linux Kernel Semaphores

• Counting semaphores – before entering critical section, must call function

down• If the value of the counter is greater than 0, decrement

the counter, allow the process to execute.• If the value of the counter is less than or equal to 0,

down decrements the counter, and the process is added to the wait queue and enters the sleeping state.

– Reduces the overhead due to busy waiting

– when a process exits its critical section, must call function up

• If the value of the counter is greater than or equal to 0, increments counter

• If the value of the counter is less than 0, up increments the counter, and a process from the wait queue is awakened to execute its critical section


Linux System V Semaphores

• accessible via the system call interface• Semaphore arrays

– Protect a group of related resources– Before a process can access resources

protected by a semaphore array, the kernel requires that there be sufficient available resources to satisfy the process’s request

– Otherwise, kernel blocks requesting process until resources become available


Windows XP Synchronization Tools

• Dispatcher objects– states: signaled vs. unsignaled– operation: wait

• specify maximum waiting time

– variations• Event, Mutex, Semaphore, Waitable timer


Windows XP kernel synchronization

• Spin lock• Queued spin lock

– Guarantees FIFO ordering of requests

• Fast mutex– Like a mutex, but more efficient– Cannot specify maximum wait time– Reacquisition by owning thread causes

deadlock

• Executive resource lock– One lock holder in exclusive mode– Many lock holders in shared mode


Windows XP: Other synchronization tools

• Critical section object– Like mutex, but only for threads of same

process– Faster than mutex, no maximum wait time

• Timer-queue timer– Waitable timer objects combined with thread

pool

• Interlocked variable access– Atomic operations on variables

• Interlocked singly-linked lists– Atomic insertion and deletion


Monitor

• Programming language construct – Contains data and procedures needed

to access shared resource• resource accessible only within the monitor

• Supports:– mutual exclusion– synchronization

• Dijkstra, Brinch-Hansen, Hoare


Monitor: mutual exclusion

• Entry to monitor is controlled• Resource access using monitor:

– thread must call monitor entry routine– only one thread is allowed into monitor– other threads must wait


Monitor: mutual exclusion

• Resource release using monitor:– Monitor entry routine alerts one

waiting thread to acquire resource and enter monitor

– Higher priority given to waiting threads than ones newly arrived• Avoids indefinite postponement


Monitor: synchronization

• Special monitor variable: condition variable

• every condition variable has associated queue

• operations:– wait(condVar)

thread is suspended– signal(condVar)

suspended thread may resume


Monitor: condition variables

• Before a thread can reenter the monitor, the thread calling signal must first exit monitor– Signal-and-exit monitor

• Requires thread to exit the monitor immediately upon signaling


Monitor: condition variables

• Signal-and-continue monitor– Allows thread inside monitor to signal

that the monitor will soon become available

– Still maintain lock on the monitor until thread exits monitor

– Thread can exit monitor by waiting on a condition variable or by completing execution of code protected by monitor


Dining Philosophers Example

monitor dp {enum {thinking, hungry, eating} state[5];condition self[5];void pickup(int i) // following slidesvoid putdown(int i) // following

slidesvoid test(int i) // following

slidesvoid init() {for (int i = 0; i < 5; i++)state[i] = thinking;}

}


Dining Philosophers

void pickup(int i) {state[i] = hungry;test(i);if (state[i] != eating)

self[i].wait();}


Dining Philosophers

void putdown(int i) {state[i] = thinking;// test left and right

neighborstest((i+4) % 5);test((i+1) % 5);

}


Dining Philosophers

void test(int i) {if ( (state[(i + 4) % 5] != eating)

&& (state[i] == hungry) && (state[(i + 1) % 5] != eating)) {

state[i] = eating;self[i].signal();

}

}


Java Monitors

• enables thread mutual exclusion and synchronization

• Signal-and-continue monitors– Allow a thread to signal that the

monitor will soon become available– Maintain a lock on monitor until thread

exits monitor

• method keyword synchronized


Java Monitors

• wait method– releases lock on monitor,

thread is placed in wait set– condition variable is “this” object– when thread reenters monitor, reason

for waiting may not be met

• notify and notifyAll– signal waiting thread(s)


Agenda for next week:

• Homework:– implement Dining Philosophers with Java

monitor

• Chapter 7– Deadlock

• Chapter 8– Processor scheduling

• Read ahead !

Documents

Operating Systems Unit 3: – Concurrent execution mutual exclusion – Concurrent programming semaphore monitor Operating Systems