【操作系统概念】【恐龙书】笔记六——第六章 进程同步

Chapter 6: Process Synchronization

问题的提出:彼此合作的进程之间可以用共享逻辑地址空间的方式来实现,共享逻辑地址空间,也就是共享代码区和数据区,会导致数据不一致,所以介绍一些避免数据不一致的机制。

6.1Background

Concurrent access to shared data may result in data inconsistency

Maintaining data consistency requires mechanisms to ensure the orderly execution of cooperating processes

Suppose that we wanted to provide a solution to the consumer-producer problem that fills all the buffers. We can do so by having an integer count that keeps track of the number of full buffers. Initially, count is set to 0. It is incremented by the producer after it produces a new buffer and is decremented by the consumer after it consumes a buffer.

Producer

item buffer[BUFFER_SIZE];

int in = 0;

int out = 0;

 

while (true) {

/* Produce an item */

while (((in + 1) % BUFFER_SIZE)== out)

; /* do nothing--no free buffers */

 

buffer[in] = item;

in = (in + 1) % BUFFER SIZE;

}

Consumer

while (true) {

while (in == out)

; /* do nothing -- nothing to consume */

 

/* remove an item from buffer */

item = buffer[out];

out = (out + 1) % BUFFER_SIZE;

return item;

}

Producer:

while (true) {

 

/* produce an item and put in nextProduced */

while (count == BUFFER_SIZE)

; // do nothing

buffer [in] = nextProduced;

in = (in + 1) % BUFFER_SIZE;

count++;

}

Consumer:

while (true) {

 

while (count == 0)

; // do nothing

nextConsumed = buffer[out];

out = (out + 1) % BUFFER_SIZE;

count--;

/* consume the item in nextConsumed */

}

Race Condition

count++ could be implemented as

register1 = count

register1 = register1 + 1

count = register1

count-- could be implemented as

register2 = count

register2 = register2 - 1

count = register2

Consider this execution interleaving with “count = 5” initially:

S0: producer execute register1 = count {register1 = 5}

S1: producer execute register1 = register1 + 1 {register1 = 6}

S2: consumer execute register2 = count {register2 = 5}

S3: consumer execute register2 = register2 - 1 {register2 = 4}

S4: producer execute count = register1 {count = 6 }

S5: consumer execute count = register2 {count = 4}

6.2The Critical-Section Problem

临界区:一个代码段,在这里进程可以修改共同变量、升级一个表、写一个文件等等。

Solution to Critical-Section Problem

1.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

  • Assume that each process executes at a nonzero speed

  • No assumption concerning relative speed of the N processes

Algorithm (1) for Process Pi Pj

Pi:

do {

while (turn != i) ;//entry section

critical section

turn = j;//exit section

remainder section

} while (1);

Pj:

do {

while (turn != j) ;//entry section

critical section

turn = i;//exit section

remainder section

} while (1);

只能一个进程轮一次

Algorithm (2) for Process Pi Pj

兩個人同時爲true,但是這個幾率比較小

do {

flag[i] = TRUE;//entry section

while (flag[j]) ;//entry section

critical section

flag[i] = false;//exit section

remainder section

} while (1);

do {

flag[j] = TRUE;//entry section

while (flag[i]) ;//entry section

critical section

flag[j] = false;//exit section

remainder section

} while (1);

6.3Peterson’s Solution

Two-process solution

Assume that the LOAD and STORE instructions are atomic; that is, cannot be interrupted.

The two processes share two variables:

int turn;

Boolean flag[2];

The variable turn indicates whose turn it is to enter the critical section.

The flag array is used to indicate if a process is ready to enter the critical section. flag[i] = true implies that process Pi is ready!

Algorithm (3) for Process Pi Pj

存在busy waiting的问题

多个Process还是会有Starvation的问题,aging也不能解决。

while (true) {

flag[i] = TRUE;

turn = j;

while ( flag[j] && turn == j);

CRITICAL SECTION

flag[i] = FALSE;

REMAINDER SECTION

}

while (true) {

flag[j] = TRUE;

turn = i;

while ( flag[i] && turn == i);

CRITICAL SECTION

flag[j] = FALSE;

REMAINDER SECTION

}

6.4Synchronization Hardware

Many systems provide hardware support for critical section code

Uniprocessors – could disable interrupts

  • Currently running code would execute without preemption

  • Generally too inefficient on multiprocessor systems - Operating systems using this not broadly scalable

Modern machines provide special atomic hardware instructions

Atomic = non-interruptable

  • Either test memory word and set value

  • Or swap contents of two memory words

Solution to Critical-section Problem Using Locks

do {

acquire lock

critical section

release lock

remainder section

} while (TRUE);

TestAndndSet Instruction

boolean TestAndSet (boolean *target)

{

boolean rv = *target;

*target = TRUE;

return rv:

}

Solution using TestAndSet

Shared boolean variable lock, initialized to false.

Solution:

while (true) {

while ( TestAndSet (&lock ))

; /* do nothing

// critical section

lock = FALSE;

// remainder section

}

Swap Instruction

void Swap (boolean *a, boolean *b)

{

boolean temp = *a;

*a = *b;

*b = temp;

}

Solution using Swap

Shared Boolean variable lock initialized to FALSE; Each process has a local Boolean variable key.

Solution:(不满足bounded-waiting)

while (true) {

key = TRUE;

while ( key == TRUE)

Swap (&lock, &key );

// critical section

lock = FALSE;

// remainder section

}

Bounded-waiting Mutual Exclusion with TestandSet()跟Peterson’s solution多程序版本比较一下,这个不会有饿死的问题。

do {

waiting[i] = TRUE;

key = TRUE;

while (waiting[i] && key)

key = TestAndSet(&lock);

waiting[i] = FALSE;

// critical section

j = (i + 1) % n;

while ((j != i) && !waiting[j])

j = (j + 1) % n;

if (j == i)

lock = FALSE; //要么把lock设为false

else

waiting[j] = FALSE; //要么把waiting[j]设为false,

//让另一个进程进入临界区

// remainder section

} while (TRUE);

Mutex locks(locks that provide mutual exclusion)

Mutual exclusion

A process must acquire the lock before entering a critical section

It release the lock when it exits the critical section

A variable available: indicate if the lock is available

acquire(S) {

while (!available)

; /* busy wait */

available = false;

}

release() {

available = true;

}

6.5Semaphores

Synchronization tool that does not require busy waiting

Semaphore S – integer variable

Two standard operations modify S: wait() and signal()

-Originally called P(), Dutch proberen(test), and V(), verhogen(increment),

Less complicated than hardware solutions

Can only be accessed via two indivisible (atomic) operations

wait (S) {

while S <= 0

; // no-op

S--;

}

signal (S) {

S++;

}

Semaphore as General Synchronization Tool

Counting semaphore – integer value can range over an unrestricted domain

Binary semaphore – integer value can range only between 0 and 1; can be simpler to implement, also known as mutex locks.

Can implement a counting semaphore S as a binary semaphore

Provides mutual exclusion

Semaphore(mutex, 1); // declare semaphore mutex, initialized to 1

do {

wait (mutex);

// critical Section

signal (mutex);

// remainder section

} while (TRUE);

typedef struct {

int value;

struct process *list;//等待信号量的进程被加到list of processes

} semaphore;

 

#define Semaphore(name, value) \

semaphore _#name = {value, 0}, \

*name = &_#name

6.5.2 Semaphore Implementation

Must guarantee that no two processes can execute wait () and signal () on the same semaphore at the same time

Thus, implementation becomes the critical section problem where the wait and signal code are placed in the critical section.

-Could now have busy waiting in critical section implementation

--But implementation code is short

--Little busy waiting if critical section rarely occupied

Note that applications may spend lots of time in critical sections and therefore this is not a good solution.

Busy waiting: loop continuously, also called “spinlock”

Semaphore Implementation without Busy Waiting (1/2)

With each semaphore there is an associated waiting queue. Each entry in a waiting queue has two data items:

  • value (of type integer)

  • pointer to next record in the list

Two operations:

block – place the process invoking the operation on the appropriate waiting queue.

wakeup – remove one of processes in the waiting queue and place it in the ready queue.

typedef struct {

int value;

struct process *list;

} semaphore;

Implementation of wait:

wait(semaphore *S) {

S->value--;

if (S->value < 0) {

add this process to S->list;

block();

}

}

Implementation of signal:

signal(semaphore *S) {

S->value++;

if (S->value <= 0) {

remove a process P from S->list;

wakeup(P);

}

}

6.5.3Deadlock and Starvation

Deadlock – two or more processes are waiting indefinitely for an event that can be caused by only one of the waiting processes

Let S and Q be two semaphores initialized to 1

P0 P1

wait (S); wait (Q);

wait (Q); wait (S);//P0必须等P1先signal(Q),而P1必须等P0 signal(S)

... …

signal (S); signal (Q);

signal (Q); signal (S);

Starvation – indefinite blocking. A process may never be removed from the semaphore queue in which it is suspended.

Priority Inversion - Scheduling problem when lower-priority process holds a lock needed by higher-priority process

Scheduling都是Priority Scheduling。

 

【操作系统概念】【恐龙书】笔记六——第六章 进程同步

Priority Inheritance Protocol放进linux

Priority Ceiling Protocol没有放进linux

6.6Classic Problems of Synchronization

6.6.1Bounded-Buffer Problem

N buffers, each can hold one item

Semaphore mutex initialized to the value 1

Semaphore full initialized to the value 0

Semaphore empty initialized to the value N.

producer与consumer是对称的,producer生产满的buffer给consumer/consumer生产空的buffer给producer

producer process

 

do {

// produce an item

wait (empty);

wait (mutex);

 

// add the item to the buffer

 

signal (mutex);

signal (full);

} while (TRUE);

consumer process

 

do {

wait (full);

wait (mutex);

 

// remove an item from buffer

 

signal (mutex);

signal (empty);

 

// consume the item

 

} while (TRUE);

 

6.6.2Readers and Writers Problem不对称

A data set is shared among a number of concurrent processes

  • Readers – only read the data set; they do not perform any updates

  • Writers – can both read and write

Problem – allow multiple readers to read at the same time. Only one single writer can access the shared data at the same time

Shared Data

  • Data set

  • Semaphore mutex initialized to 1

  • Semaphore wrt initialized to 1(被第一个或最后一个进入/离开临界区的reader使用)

  • Integer readcount initialized to 0

The structure of a writer process

 

do {

wait (wrt) ;

 

// writing is performed

 

signal (wrt) ;

} while (TRUE);

 

 

 

The structure of a reader process

 

do {

wait (mutex) ;

readcount ++ ;

if (readcount == 1)

wait (wrt) ;

signal (mutex)

 

// reading is performed

 

wait (mutex) ;

readcount - - ;

if (readcount == 0)

signal (wrt) ;

signal (mutex) ;

} while (TRUE);

 

6.6.3Dining-Philosophers Problem跟monitor的方法比较

 

Shared data

  • Bowl of rice (data set)

  • Semaphore chopstick [5] initialized to 1

The structure of Philosopher i:

 

While (true) {

wait ( chopstick[i] );

wait ( chopStick[ (i + 1) % 5] );

 

// eat

 

signal ( chopstick[i] );

signal (chopstick[ (i + 1) % 5] );

 

// think

 

}

如果五个哲学家同时拿起右边的筷子,就会死锁。

Problems with Semaphores

Correct use of semaphore operations:

  • signal (mutex) …. wait (mutex)

  • wait (mutex) … wait (mutex)

  • Omitting of wait (mutex) or signal (mutex) (or both)

二元號誌- binary semaphore

二元號誌的值只限定為 0 或 1。

利用硬體對二元數值的運算支援,二元號誌的實作要比計數號誌簡單快速得多。

可以利用二元號誌來實作計數號誌。

計數號誌可以利用兩個二元號誌以及一個整數實作。

void wait(S) {

wait(S1);

C--;

if (C < 0) {

signal(S1);

wait(S2);

}

signal(S1);

}

void signal(S) {

wait( S1);

C++;

if (C <= 0)

signal(S2);

else

signal(S1);

}

臨界區域 - critical region

臨界區域的使用非常方便。

以下宣告一個具有共享變數 v 的臨界區域,在 B 條件式成立下,如果沒有其他行程在此臨界區域中執行,就會執行 S 敘述:

region v when B do S;

利用臨界區域來實作,程式設計師不用煩惱同步的問題,只要正確地把問題描述在臨界區域內。

有限緩衝區問題可以用臨界區域來簡單地解決同步的問題。

生產者與消耗者程式可以分別以臨界區域實作如下。

Producer:

region buffer when (count < n) {

pool[in] = nextp;

in = (in + 1) % n;

count++;

}

Consumer:

region buffer when (count > 0) {

nextc = pool[out];

out = (out + 1) % n;

count--;

}

臨界區域 region v when B do S 可利用 mutex、first_delay 及 second_delay 三個號誌實作。

  • mutex 號誌是用來確保臨界區的互斥條件成立。

  • 如果行程因為 B 為 FALSE 而無法進入臨界區,該行程將會在號誌 first_delay 等待。

  • 在號誌 first_delay 等待的行程重新檢查 B 值之前,會離開號誌 first_delay,而在號誌 second_delay 等待。

  • 分成first_delay 與 second_delay兩段式等待的原因,是為了要避免行程持續忙碌地檢查 B 值。

  • 當一個行程離開了臨界區之後,可能因為執行了敘述 S 而改變了 B 的值,所以需要重新檢查。

ch6 P43頁很重要://变量初始化:

mutex=1;first_delay=0;second_delay=0;first_count=0;second_count=0;

wait(mutex);

while (!B) {

first_count++;

if (second_count > 0)

signal(second_delay);

else

signal(mutex);

wait(first_delay);

first_count--;

second_count++;

if (first_count > 0)

signal(first_delay);

else

signal(second_delay);

wait(second_delay);

second_count--;

}

S;

if (first_count > 0)

signal(first_delay);

else if (second_count > 0)

signal(second_delay);

else

signal(mutex);

wait(mutex);

while (!B) {

first_count++;

signal(mutex);

wait(first_delay);

first_count--;

}

S;

if (first_count > 0)

signal(first_delay);

else

signal(mutex);

else

signal(first_delay);

wait(first_delay);

first_count--;

}

S;

if (first_count > 0)

signal(first_delay);

else if (first_count > 0)

signal(first_delay);

else

signal(mutex);

wait(mutex);

while (!B) {

first_count++;

if (first_count > 0)

signal(first_delay);

else

signal(mutex);

wait(first_delay);

first_count--;

}

S;

if (first_count > 0)

signal(first_delay);

else

signal(mutex);

6.7Monitors (conditional variables)

A high-level abstraction that provides a convenient and effective mechanism for process synchronization

Only one process may be active within the monitor at a time

monitor monitor-name

{

// shared variable declarations

procedure P1 (…) { …. }

 

procedure Pn (…) {……}

 

Initialization code ( ….) { … }

}

}

Schematic view of a Monitor:

 

 

condition x, y;

Two operations on a condition variable:

x.wait () – a process that invokes the operation is suspended.

x.signal () – resumes one of processes (if any) that invoked x.wait ()

Solution to Dining Philosophers(没有死锁的问题)

monitor DP

{

enum { THINKING, HUNGRY, EATING) state [5] ;

condition self [5];

 

void pickup (int i) {

state[i] = HUNGRY;

test(i);

if (state[i] != EATING) self [i].wait;

}

 

void putdown (int i) {

state[i] = THINKING;

// test left and right neighbors

test((i + 4) % 5);

test((i + 1) % 5);

}

 

void test (int i) {

if ( (state[(i + 4) % 5] != EATING) &&

(state[i] == HUNGRY) &&

(state[(i + 1) % 5] != EATING) ) {

state[i] = EATING ;

self[i].signal () ;

}

}

 

initialization_code() {

for (int i = 0; i < 5; i++)

state[i] = THINKING;

}

}

 

Each philosopher I invokes the operations pickup() and putdown() in the following sequence:

 

dp.pickup (i)

 

EAT

 

dp.putdown (i)

Monitor Implementation Using Semaphores

Variables

semaphore mutex; // (initially = 1)

semaphore next; // (initially = 0)

int next-count = 0;

 

Each procedure F will be replaced by

 

wait(mutex);

body of F;

if (next_count > 0)

signal(next)

else

signal(mutex);

 

Mutual exclusion within a monitor is ensured.

 

For each condition variable x, we have:

 

semaphore x_sem; // (initially = 0)

int x-count = 0;

 

The operation x.wait can be implemented as:

 

x-count++;

if (next_count > 0)

signal(next);

else

signal(mutex);

wait(x_sem);

x-count--;

The operation x.signal can be implemented as:

 

if (x-count > 0) {

next_count++;

signal(x_sem);

wait(next);

next_count--;

}

 

Linux Synchronization

Linux:

Prior to kernel Version 2.6, disables interrupts to implement short critical sections

Version 2.6 and later, fully preemptive

Linux provides:

semaphores

spin locks

6.8Synchronization Examples

Alternative Approaches

As the number of processing core increase, it is more difficult to be thread save from race conditions and deadlocks.

Transactional Memory

Idea adopted from database theory

Memory transaction: a sequence of memory read-write operations that are atomic.

If all operations in a transaction are complete, it is committed; otherwise it must be aborted and rolled back.

The transactional memory system, not the developer, is responsible for guaranteeing atomicity.

No locks, so no deadlock.

Software/Hardware transaction memory (STM/HTM)

OpenMP

  • Any code following #progma omp parallel is performed by a number of threads equal to the number of processing cores.

  • The thread creation and management are handled by the OpenMP library, not developer.

  • The code region following #progma omp critical is a critical section, only one thread may be active at a time.

Functional Programming Languages

Imperative (or procedural) Language

  • C, C++, Java, C#

  • state-based, by mutable variables …

  • Flow of the algorithm is crucial to correctness.

Functional programming language

  • Erlang, Scala (object-oriented)

  • Do not maintain states

  • Immutable variables, so no need to lock at all.