Process Synchronization in Operating Systems: A Comprehensive Guide, Lecture notes of Operating Systems

Download Process Synchronization in Operating Systems: A Comprehensive Guide and more Lecture notes Operating Systems in PDF only on Docsity!

6: Process Synchronization

Jerry Breecher

OPERATING SYSTEMS

PROCESS SYNCHRONIZATION

6: Process Synchronization

What Is In This Chapter?

-^ This is about getting processes to coordinate with each other. •^ How do processes work with resources that must be sharedbetween them? •^ How do we go about acquiring locks to protect regions of memory? •^ How is synchronization really used?

OPERATING SYSTEMSynchronization

6: Process Synchronization

PROCESS

SYNCHRONIZATION^ A^ producer

process "produces" information "consumed" by a

consumer

process.

Here are the variables needed to define the problem:

The ProducerConsumer Problem

#define BUFFER_SIZE 10typedef struct {DATA

data;

} item;item^

buffer[BUFFER_SIZE];

int^

in = 0;

// Location

of next input to buffer

int^

out = 0;

// Location

of next removal from buffer

int^ counter = 0;

// Number of buffers currently full

Consider the code segments on the next page:• Does it work?• Are all buffers utilized?

6: Process Synchronization

PROCESS

SYNCHRONIZATION^ A^ producer

process "produces" information "consumed" by a

consumer

process.

The ProducerConsumer Problem

item^ nextProduced;while^ (TRUE) {while

(counter ==

BUFFER_SIZE);

buffer[in] = nextProduced;in = (in + 1) % BUFFER_SIZE;counter++;}

item^ nextConsumed;while^ (TRUE) {while

(counter ==

#define BUFFER_SIZE 10typedef struct {DATA^ nextConsumed = buffer[out];out =^ (out + 1) %BUFFER_SIZE;counter--;}

data; } item;item^ buffer[BUFFER_SIZE]; int^ in = 0; int^ out =^ 0; int^

counter =

PRODUCER

CONSUMER

producer^

consumer

6: Process Synchronization

A section of code, common to n cooperating processes, in which the

processes may be accessing common variables.

A Critical Section Environment contains: Entry Section

Code requesting entry into the critical section.

Critical Section

Code in which only one process can execute at any one time.

Exit Section

The end of the critical section, releasing or allowing others in.

Remainder Section

Rest of the code AFTER the critical section.

PROCESS

SYNCHRONIZATION

Critical Sections

6: Process Synchronization

The critical section must ENFORCE ALL THREE of the following rules: Mutual Exclusion:

No more than one process can execute in its critical sectionat one time.

Progress:

If no one is in the critical section and someone wants in,then those processes not in their remainder section mustbe able to decide in a finite time who should go in.

Bounded Wait:

PROCESS^ All requesters must eventually be let into the criticalsection.

SYNCHRONIZATION

Critical Sections

6: Process Synchronization

Here we try a succession of increasingly complicated solutions to the problem ofcreating valid entry sections.NOTE: In all examples,

i^ is the current process,

j^ the "other" process.

In

these examples, envision the same code running on two processors at the sametime. TOGGLED ACCESS:^ do {

PROCESS while ( turn ^= i );/* critical section /turn = j;/ remainder section */} while(TRUE);

SYNCHRONIZATION

Two Processes

Software Are the three Critical SectionRequirements Met?

Algorithm 1

6: Process Synchronization

FLAG FOR EACH PROCESS GIVES STATE: Each process maintains a flag indicating that it wants to get into the critical section.

It

checks the flag of the other process and doesn’t enter the critical section if that otherprocess wants to get in.

Are the three CriticalSection Requirements Met?

PROCESS

SYNCHRONIZATION

Two Processes

Software

do {

flag[i] := true;while (flag[j]) ; critical section flag [i] = false; remainder section

} while (1);

Algorithm 2

Shared variables boolean flag[2]

; initially flag [0] = flag [1] = false.

flag [i] = true

^ P ready to enter its critical section i^

6: Process Synchronization

PROCESSSYNCHRONIZATION The hardware required to support critical sections must have(minimally): • Indivisible instructions (what are they?) • Atomic load, store, test instruction. For instance, if a store andtest occur simultaneously, the test gets EITHER the old or thenew, but not some combination. • Two atomic instructions, if executed simultaneously, behave as ifexecuted sequentially.

Critical Sections

6: Process Synchronization

Disabling Interrupts

:^ Works for the Uni Processor case only. WHY?

Atomic test and set

:^ Returns parameter and sets parameter to true atomically. while ( test_and_set ( lock ) );/* critical section */lock = false;

Example of Assembler code:GET_LOCK:

IF_CLEAR_THEN_SET_BIT_AND_SKIP <bit_address>BRANCH

GET_LOCK

/* set failed */

-------^

/* set succeeded */

Must be careful if these approaches are to satisfy a bounded wait condition - mustuse round robin - requires code built around the lock instructions.

PROCESS

SYNCHRONIZATION

HardwareSolutions

6: Process Synchronization

We first need to define, for multiprocessors:^ caches,shared memory (for storage of lock variables),write through cache,write pipes. The last software solution we did ( the one we thought was correct ) may notwork on a cached multiprocessor.

Why? { Hint, is the write by one

PROCESSSYNCHRONIZATIONprocessor visible immediately to all other processors?}What changes must be made to the hardware for this program to work?

Current HardwareDilemmas

6: Process Synchronization

Does the sequence below work on a cached multiprocessor?Initially, location

a^ contains A0 and location

b^ contains B0.

a) Processor 1 writes data A1 to location

a.

b) Processor 1 sets

b^ to B1 indicating data at

a^ is valid.

c) Processor 2 waits for

b^ to take on value B1 and loops until that

change occurs.d) Processor 2 reads the value from

a.

What value is seen by Processor 2 when it reads

a?

PROCESSSYNCHRONIZATIONHow must hardware be specified to guarantee the value seen?

Current HardwareDilemmas a: A^

b:^ B

6: Process Synchronization

Hardware test and set on a multiprocessor causes^ • an explicit flush of the write to main memory and^ • the update of all other processor'

s caches.

Imagine needing to write

all^ shared data straight through the cache.

With test and set,

only^ lock locations are written out explicitly.

In not too many years, hardware will no longer support software solutionsbecause of the performance impact of doing so.

PROCESS

SYNCHRONIZATION

Current HardwareDilemmas

6: Process Synchronization

PURPOSE: We want to be able to write more complex constructs and so need a language to doso. We thus define semaphores which we assume are atomic operations:As given here, these are not atomic as written in "macro code". We define theseoperations, however, to be atomic (Protected by a hardware lock.) FORMAT:

wait ( mutex );

<-- Mutual exclusion: mutex init to 1.

WAIT ( S ):while^ ( S <= 0 );S = S - 1;^ CRITICAL SECTIONsignal( mutex );REMAINDER

SIGNAL ( S ):S = S + 1;

PROCESS

SYNCHRONIZATION

Semaphores