Interprocess communication
Download
1 / 50

Interprocess Communication - PowerPoint PPT Presentation


  • 122 Views
  • Updated On :

Interprocess Communication. P1 /* x++ */ move (0x3000), D2 add D2, 1 move D2, (0x3000). P2 /* x-- */ move (0x3000), D3 sub D3, 1 move D3, (0x3000). Basic problem. shared int x = 0 at location 0x3000. Contents of 0x3000 after P1 & P2 have run?. Race conditions.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Interprocess Communication' - chet


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Interprocess communication l.jpg

Interprocess Communication

CS 570 Operating Systems


Basic problem l.jpg

P1

/* x++ */

move (0x3000), D2

add D2, 1

move D2, (0x3000)

P2

/* x-- */

move (0x3000), D3

sub D3, 1

move D3, (0x3000)

Basic problem

shared int x = 0 at location 0x3000

Contents of 0x3000 after P1 & P2 have run?

CS 570 Operating Systems


Race conditions l.jpg
Race conditions

  • A race condition occurs when the ordering of execution between two processes (or threads) can affect the outcome of an execution.

  • In most situations, race conditions are unacceptable.

CS 570 Operating Systems


Critical sections regions informal l.jpg
Critical sections/regions (informal)

  • A section of code that ensures that only one process accesses a set of shared data. It consists of:

    • Entry (negotiation)

    • Critical section/region (mutual exclusion).

    • Exit (release)

CS 570 Operating Systems


Critical sections regions l.jpg
Critical sections/regions

  • The rest of the program is called the remainder

P1

// other code…

entry();

x++;

exit();

// other code…

P2

// other code…

entry();

x--;

exit();

// other code…

CS 570 Operating Systems


Critical sections regions6 l.jpg
Critical sections/regions

To be a critical region, the following 3 conditions must be met:

  • Mutual exclusion – No more than one process can access the shared data in the critical section.

  • Progress – If no process is accessing the shared data, then:

    • Only processes executing the entry/exit sections can affect the selection of the next process to enter the critical section.

    • The process of selection must eventually complete.

  • Bounded waiting – Once a process executes its entry section, there is an upper bound on the number of times that other processes can enter the region of mutual exclusion.

    (Note: Use this definition from Silberschatz et al. instead of the one provided by Tanenbaum on all homework, exams, etc.)

CS 570 Operating Systems


Critical sections regions7 l.jpg
Critical sections/regions

  • We will study the following types of solutions:

    • software only

    • hardware/software

    • abstractions of the critical region problem

      • data types

      • language constructs

CS 570 Operating Systems


Two process critical regions l.jpg

shared int turn = 0;

foobar() {

/* entry */

while (turn != process_ident)

do nothing

/* critical region code */

/* exit */

turn = (turn + 1) % 2;

}

shared bool locked = false;

foobar() {

/* entry */

while (locked)

do nothing

locked = true;

/* critical region code */

/* exit */

locked = false;

}

Two process critical regions?

spin locks

CS 570 Operating Systems


Peterson s 2 process solution 1981 l.jpg

void enter_region(int process)

{

int other = (process + 1) % 2; /* other PID */

interested[process] = true;

turn = process; /* set flag */

/* Busy-wait until the following happens

* it is our turn & the other process is not interested

* it is the other person’s turn. Note that if the

* turn is the other processes, it means that they

* must have set turn after us, so we should go first.

*/

while (turn == process && interested[other] == true)

no-op;

}

void exit_region(int process) {

/* We’re all done, no longer interested */

interested[process] = false;

}

Peterson’s 2 process solution (1981)

shared boolean interested[2] = {false, false};

shared int turn;

CS 570 Operating Systems


Ensuring 0 1 1 0 l.jpg
Ensuring 0 + 1 – 1 = 0:

  • With Peterson’s solution we would write:

  • Other solutions such as the Bakery algorithm (not covered) provide solutions for more than 2 processes.

P1

// other code…

entry(0);

x++;

exit(0);

// other code…

P2

// other code…

entry(1);

x--;

exit(1);

// other code…

CS 570 Operating Systems


Atomic operations l.jpg
Atomic operations

  • Recall our earlier experience with x++.

    move (0x3000), D2

    add D2, 1

    move D2, (0x3000)

  • Atomic instructions cannot be interrupted.

CS 570 Operating Systems


Hardware assistance l.jpg
Hardware assistance

  • Most modern CPUs provide atomic (non interruptible) instructions

    • test and set lock

    • swap word

  • We will focus only on test and set lock

CS 570 Operating Systems


Test and set lock l.jpg
Test and set lock

  • Pseudocode demonstrating functionality:

    boolean TestAndSetLock(boolean *Target) {

    boolean Result;

    Result = *Target

    *Target = true;

    return Result;

    }

CS 570 Operating Systems


Mutual exclusion with tsl l.jpg
Mutual exclusion with TSL

shared boolean PreventEntry = false;

repeat

// entry

while TestAndSetLock(&PreventEntry)

no-op;

// mutual exclusion...

PreventEntry = false; //exit

until NoLongerNeeded();

Is this a critical section? Why or why not?

CS 570 Operating Systems


Avoiding busy waiting l.jpg
Avoiding busy waiting

  • So far, all of our solutions have relied on spin locks.

  • There should be a better way…

CS 570 Operating Systems


Semaphores dijkstra 1965 l.jpg
semaphores (Dijkstra 1965)

  • A semaphore is an abstract data type for synchronization.

  • A semaphore contains an integer variable which is accessed by two operations known by many different names:

* We will use down/up in this class, but you should be able to recognize all three.

CS 570 Operating Systems


Semaphores l.jpg
semaphores

  • Libraries frequently pick their own nonstandard names:

  • When used properly, semaphores can implement critical regions.

CS 570 Operating Systems


Semaphore initialization l.jpg
semaphore initialization

  • When a semaphore is created it is given an initial value. Actual implementation varies, but we will write:

    semaphore s = 1; // initialize to 1

  • It is important to always initialize your semaphores.

CS 570 Operating Systems


Semaphore operations l.jpg
semaphore operations

  • down – Decrement the counter value. If the counter is less than zero, block.

  • up – Increment the counter value. If processes have blocked on the semaphore, unblock one of the processes.

CS 570 Operating Systems


Critical regions semaphores l.jpg
Critical regions & semaphores

shared semaphore Sem = 1;

/* common code */

enter_region() {

Sem.down();

}

exit_region() {

Sem.up();

}

CS 570 Operating Systems


Ensuring 0 1 1 0 again l.jpg

P1

Sem.down();

x++;

Sem.up();

P2

Sem.down();

x--;

Sem.up();

Ensuring 0 + 1 – 1 = 0 (again):

shared int x = 0;

shared semaphore Sem = 1;

CS 570 Operating Systems


The producer consumer problem solution with semaphores l.jpg
The producer/consumer problemsolution with semaphores

/* for implementing the critical region */

shared semaphore mutex = 1;

/* items in buffer */

shared semaphore Unconsumed = 0;

/* space in buffer */

shared semaphore AvailableSlots = BufferSize;

shared BufferADT Buffer; /* queue, tree, etc */

CS 570 Operating Systems


Producer process l.jpg
Producer process

void producer() {

ItemType Item;

while (true) {

Item = new ItemType();

/* make sure we have room */

AvailableSlots.down();

/* Access buffer exclusively */

mutex.down();

Buffer.Insert(Item);

mutex.up();

Unconsumed.up(); /* inform consumer */

}

}

CS 570 Operating Systems


Consumer process l.jpg
Consumer process

void consumer() {

ItemType Item;

while (true) {

// Block until something to consume

Unconsumed.down();

// Access buffer exclusively

mutex.down();

Item = Buffer.Remove();

mutex.up();

AvailableSlots.up();

consume(Item); // use Item

}

}

CS 570 Operating Systems


Barriers with semaphores l.jpg
Barriers with semaphores

  • In general, when we want a process to block until something else occurs, we use a semaphore initialized to zero:

CS 570 Operating Systems


Barriers with semaphores26 l.jpg
Barriers with semaphores

  • Suppose PA has spawned PB, PC, and PD and we wish PA to wait until its children have terminated:

CS 570 Operating Systems


Barriers with semaphores27 l.jpg
Barriers with semaphores

CS 570 Operating Systems


Down semaphore implementation l.jpg
Down semaphore implementation

down(Semaphore S) {

S.value = S.value – 1;

if (S.value < 0) {

add(ProcessId, WaitingProcesses)

set state to blocked;

}

}

CS 570 Operating Systems


Up semaphore implementation l.jpg
Up semaphore implementation

up(Sempahore S) {

S.value = S.value + 1;

if (S.value <= 0) {

// At least one waiting process.

// select a process to run

NextProcess = SelectFrom(WaitingProcesses);

set state of NextProcess to ready;

}

}

CS 570 Operating Systems


Semaphore implementation l.jpg
Semaphore implementation

  • Proposed implementation not atomic!

  • Possible solutions?

CS 570 Operating Systems


Semaphore implementation31 l.jpg
Semaphore implementation

  • Proposed implementation not atomic!

  • Possible solutions

    • disable interrupts

    • hardware/software synchronization

    • software synchronization

CS 570 Operating Systems


Mutexes l.jpg
mutexes

  • Specialized semaphore

  • Read section 2.3.6

CS 570 Operating Systems


Monitors hoare 1974 hansen 1975 l.jpg

Programming language construct which solves the critical region problem

Sample monitor from a fictional language.

A variant of monitors is supported in Java

monitor MonitorName {

variable declarations

procedure MonProc1(...) {

}

...

procedure MonProcN(...) {

}

MonitorName() {

// initialization code

}

}

Monitors (Hoare 1974/Hansen 1975)

CS 570 Operating Systems


Monitors l.jpg
Monitors region problem

  • Provides encapsulation of shared data.

    • Data declared in monitor.

    • Data cannot be accessed outside the monitor.

  • Compiler generates critical region code

  • Only one active process in the monitor at any given time.

CS 570 Operating Systems


A monitor conundrum l.jpg
A monitor conundrum region problem

  • Suppose a process enters the monitor and finds a resource is not available.

  • Example:

    Producer/Consumer problem

    Producer calls an AddItem(Item) method

    Buffer used for products is full.

    It would be nice to do something other than exit without adding the item and trying to invoke the method again...

CS 570 Operating Systems


Monitors condition variables l.jpg
Monitors: condition variables region problem

  • Condition variables allow us to do this.

  • Abstract data type

    • Similar to semaphores

    • Two operations

      • wait – similar to semaphore wait (down)

      • signal – similar to semaphore signal (up)

      • no need to initialize, value always initialized to 0

CS 570 Operating Systems


Wait operation l.jpg
wait operation region problem

  • Decrements counter and blocks caller.

  • As caller is no longer active, next process allowed to enter monitor.

CS 570 Operating Systems


Signal operation l.jpg
signal operation region problem

if no process blocked on condition variable {

no op

} else {

exit from monitor

start blocked process

}

This behavior was specified by Brinch Hansen, there are other possibilities which we will not study. They vary only in the else clause.

CS 570 Operating Systems


Monitor producer consumer l.jpg
Monitor producer/consumer region problem

CS 570 Operating Systems


Monitor producer consumer40 l.jpg
Monitor producer/consumer region problem

CS 570 Operating Systems


Monitor producer consumer41 l.jpg
Monitor producer/consumer region problem

CS 570 Operating Systems


Test set lock critical region l.jpg

shared boolean waiting[N] = {false, false, ..., false}; region problem

shared boolean lock;

// process local data

int j;

boolean key;

repeat

// entry - Either we obtain the key or someone sets our waiting bit to false, indicating that we may proceed.

waiting[i] = true;

key = true;

while (waiting[i] && key)

key = TestAndSetLock(lock);

waiting[i] = false;

// critical section

// exit – Set next waiting process to no longer waiting or if // we make it all the way through release the lock.

j = (i+1) % n;

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

j = (j+1) % n;

if (j == i)

lock = false; // nobody was waiting, unlock

else

waiting[j] = false;

// remainder

until done;

Test & Set Lock Critical Region

for your information only – you will not be tested over this

CS 570 Operating Systems


Message passing l.jpg
Message passing region problem

  • Interprocess communication without need for message passing

  • Primitives

    • send(destination, message)

    • receive(source, message)

CS 570 Operating Systems


Defining source and destination l.jpg

Processes region problem

processes must have unique names

Mailboxes (ports)

mailboxes must have unique names

multiple receivers possible

Defining source and destination

CS 570 Operating Systems


Message delivery l.jpg
Message delivery region problem

  • We will assume reliable delivery

  • In reality

    • Messages can be lost on networks

    • Reliable delivery subject of networking class

    • Basic idea (better schemes exist)

      • Receiver sends acknowledgement

      • If sender does not receive acknowledgement within reasonable amount of time, retransmits message.

CS 570 Operating Systems


Buffers l.jpg
Buffers region problem

  • Messages must be stored in a temporary area until the receiver retrieves them.

  • Process blocks if there is not enough room.

CS 570 Operating Systems


Buffer capacity l.jpg
Buffer capacity region problem

  • Size of buffer affects behavior

    • zero: Sender blocks until receiver reads message.

      • Enforces coordination, known as a rendez-vous.

      • Can be used for remote procedure calls

    • bounded: Asynchronous call as long as there is room in buffer

    • unbounded: Always asynchronous

CS 570 Operating Systems


Implementation issues l.jpg
Implementation issues region problem

  • Assuring reliable delivery

  • Naming processes/mailboxes uniquely

  • Buffer size

CS 570 Operating Systems


Producer consumer problem l.jpg
Producer consumer problem region problem

CS 570 Operating Systems


Slide50 l.jpg

CS 570 Operating Systems region problem