Slide 17-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 17.

Operating Systems: A Modern Perspective, Chapter 17

Slide 17-1

Copyright © 2004 Pearson Education, Inc.


Slide 17-2


17DistributedComputing


Slide 17-3


Distributed Computation Using Files

Part 1Part 1 Part 2Part 2

f1 = open(toPart2, …);while(…){ write(f1. …);}close(f1);

…f2 = open(toPart1, …);while(…){ write(f2. …);}close(f2);

f2 = open(toPart2, …);while(…){ read(f1, …);}close(f1);

f2 = open(toPart1, …);while(…){ read(f2, …);}close(f2);


Slide 17-4


Finer Grained Sharing

• Distributed computing can be for:– Speed up (simultaneous execution)– Simplify data management (consistency)

• Last Generation: programming languages (and programmers) do serial computation– Want to share global data– Speed up is a specialist’s domain

• Procedure is basic unit of abstraction– Abstract data type behavior


Slide 17-5


Finer Grained Sharing (2)

• Newer computing model– Partition into processes/threads– Message passing communication

• New OS & language support– Remote procedures– Remote objects with remote method invocation– Distributed process management– Shared memory– Distributed virtual memory

• … but first, how to partition the computations?


Slide 17-6


Data Partition

Serial Formof code

while(…){…}

Distribute DataDistribute Data

Serial Form Serial Form Serial Form

Execute all data streams simultaneously


Slide 17-7


Functional Partition

Serial Formof code

A Partition

The Parts


Slide 17-8


Functional Partition (2)

• Software is composed from procedures• All programmers are familiar with procedural

abstraction – exploit procedure model• Allow each function to be a blob• Implement each blob as a thread/process• OS provide network IPC mechanism for serial use

of distributed functions– TCP/IP– Messages– “Procedure call” protocol between client and server


Slide 17-9


Record Sharing

Part 1Part 1 Part 2Part 2

…while(…){ writeSharedRecord(…); readSharedRecord(…);}…

…while(…){ readSharedRecord(…); writeSharedRecord(…);}…


Slide 17-10


Traditional Memory Interfaces

ProcessProcess

VirtualMemory

VirtualMemory File

Management

FileManagement

PhysicalMemory

PhysicalMemory

StorageDevices

StorageDevices

Device Interface

Secondary Memory InterfacePrimary Memory Interface


Slide 17-11


Exploiting Normal Interfaces to the Memory System

ProcessProcess

VirtualMemory

VirtualMemory File

Management

FileManagement

PhysicalMemory

PhysicalMemory

StorageDevices

StorageDevices

File System InterfacePrimary Memory Interface

Remote DiskClient

Remote DiskClient

Remote DiskServer

Remote DiskServer

Remote FileClient

Remote FileClient

Remote FileServer

Remote FileServer

Pri

vile

ged

Use

Onl

y


Slide 17-12


Remote Memory

ProcessProcess

FileManagement

FileManagement

Remote Memory Interface

Remote MemoryClient

Remote MemoryClient

Remote MemoryServer

Remote MemoryServer

•Static memory New language•Dynamic memory New OS interface•Low level interface

•Binding across address spaces•Shared memory malloc

•High level interface•Tuples•Objects


Slide 17-13


Distributed Virtual MemoryProcessProcess

VirtualMemory

VirtualMemory

PhysicalMemory

PhysicalMemory

StorageDevices

StorageDevices

Primary Memory Interface

Remote PagingClient

Remote PagingClient

Remote PagingServer

Remote PagingServer

StorageDevices

StorageDevices


Slide 17-14


Distributed Virtual Memory(2)

Process 1Process 1PrimaryMemory

Space

PrimaryMemory

Space LocalSecondaryMemory

LocalSecondaryMemory

VirtualAddressSpace

map

RemoteSecondaryMemory

RemoteSecondaryMemory

Server

Process 2Process 2PrimaryMemory

Space

PrimaryMemory

Space LocalSecondaryMemory

LocalSecondaryMemory

VirtualAddressSpace

map


Slide 17-15


Remote Procedure Call

int main(…) { … func(a1, a2, …, an); …}

void func(p1, p2, …, pn) { …}

int main(…) { … func(a1, a2, …, an); …}


Conventional Procedure Call Remote Procedure Call


Slide 17-16


Remote Procedure Callint main(…) { … func(a1, a2, …, an); …}


…pack(a1, msg);pack(a2, msg);…pack(an, msg);send(rpcServer, msg);// waiting ...result = receive(rpcServer);...

// Initialize the serverwhile(TRUE) { msg = receive(anyClient); unpack(msg, t1); unpack(msg, t2); … unpack(msg, tn); func(t1, t2, …, tn); pack(a1, rtnMsg); pack(a2, rtnMsg); … pack(an, rtnMsg); send(rpcServer, rtnMsg);}


Slide 17-17


Implementing RPC

• Syntax of an RPC should look as much like a local procedure call as possible

• Semantics are impossible to duplicate, but they should also be as close as possible

• The remote procedure’s execution environment will not be the same as a local procedure’s environment– Global variables– Call-by-reference– Side effects– Environment variables


Slide 17-18


Implementing RPC

int main(…) { … localF(…); … remoteF(…); …}

void localF(…) { … return;}

lookup(remote);pack(…);send(rpcServer, msg);receive(rpcServer);unpack(…);return;

register(remoteF);while(1) { receive(msg); unpack(msg); remoteF(…); pack(rtnMsg); send(theClient,rtnMsg);}

clientStub

main

theClient

void remoteF(…) { … return;}

void register(…) { …}

void lookup(…) { …}

Name Server

rpcServer

FirstTimeOnly


Slide 17-19


Compiling an RPC

• callRemote(remoteF, …);• remoteF(…);

– Compile time– Link time– Dynamic binding


Slide 17-20


Sun XDR Conversion

Client

RPC Server

XDRconversion

XDRconversion

XDR Spec

XDRconversion

XDRconversion

Network XDR Transmit


Slide 17-21


Sun rpcgen Files

main.cmain.c rproc.xrproc.x

rproc_clnt.crproc_clnt.c rproc.hrproc.h rproc_svc.crproc_svc.c

rproc.crproc.c

rpcgen

C compiler C compiler

RPC clientRPC client RPC serverRPC server


Slide 17-22


Distributed Object InterfaceProcessProcess

Object Interface

Remote ObjectClient

Remote ObjectClient

Remote ObjectServer

Remote ObjectServer

Local ObjectsLocal Objects

ProcessProcess

RemoteObject Interface

Remote ObjectClient

Remote ObjectClient

Remote ObjectServer

Remote ObjectServer

Local ObjectsLocal Objects

LocalObject Interface

Performance

e.g. Corba, DCOM,SOAP, …

(a) Single Interface to Objects (b) Interface to Local and Remote Objects


Slide 17-23


IDL SkeletonIDL Skeleton

The CORBA Approach

ClientClient

ObjectImplementation

ObjectImplementation

ORB InterfaceORB Interface

ORB InterfaceORB Interface

ORB Core

IDL StubIDL Stub

Stub ImplementStub Implement

IDL SkeletonIDL SkeletonDynamic Skel.Dynamic Skel.

Dynamic SkelDynamic Skel

Dynamic StubDynamic Stub

Dynamic Stub.Dynamic Stub.

Object AdaptorObject Adaptor

InterfaceRepository


Slide 17-24


Supporting the Computation• Each blob might be a process, thread, or object• Blobs should be able to run on distinct,

interconnected machines• OS must provide mechanisms for:

– Process Management• Control

• Scheduling

• Synchronization

• IPC

– Memory Management• Shared memory

– File Management – remote files

• Distributed OS or cooperating Network OSes?


Slide 17-25


Control

• Remote process/thread create/destroy

• Managing descriptors

• Deadlock


Slide 17-26


Scheduling

• Threads and processes

• Explicit scheduling

• Transparent scheduling

• Migration & load balancing

• Objects– Active vs passive– Address spaces


Slide 17-27


Migration and Load Balancing

p

p

A thread or process

Machine A

Machine B

Machine C

p

p

pp

pp

pp

p

p

p

Machine A

Machine B

Machine C

p

p

p

ppp

pp

p

p

(a) Before Balancing (b) After Balancing


Slide 17-28


Synchronization

• Distributed synchronization– No shared memory no semaphores– New approaches use logical clocks & event

ordering

• Transactions– Became a mature technology in DBMS– Multiple operations with a commit or abort

• Concurrency control– Two-phase locking


Slide 17-29


Updating a Multiple Field Record

Process pi Process pj... ...send(server, update, k, 3); send(server, update, k, 5);send(server, update, k, 6); send(server, update, k, 8);send(server, update, k, 2); send(server, update, k, 4);send(server, update, k, 8); send(server, update, k, 6);... ...


Slide 17-30


Explicit Event Ordering• Alternative technique of growing

importance in network systems• Rely on knowing the relative order of

occurrence of every event– (occurrence of y in pj) < (occurrence of x in pi)– Then can synchronize by explicitly specifying

each relation (when it is important)

advance(eventCount): Announces the occurrence of an event related to eventCount, causing it to be incremented by 1await(eventCount, v): Causes process to block as long as eventCount < v.


Slide 17-31


Producer-Consumer Solution Using Precedence

producer() { consumer() {/* i establishes local order */ /* i establishes local order */ int i = 1; int i = 1; while(TRUE) { while(TRUE) { /* Stay N–1 ahead of consumer */ /* Stay N–1 behind producer */ await(out, i-N); await(in, i); produce(buffer[(i–1) mod N]); consume(buffer[(I–1) mod N]; /* Signal a full buffer */ /* Signal an empty buffer */ advance(in); advance(out); i = i+1; i = i+1; } }} }eventcount in=0, out=0;struct buffer[N];fork(producer, 0);fork(consumer, 0);


Slide 17-32


More on EventCounts

• Notice that advance and await need not be uninterruptible

• There is no requirement for shared memory

• For full use of this mechanism, actually need to extend it a bit with a sequencer

• Underlying theory is also used to implement “virtual global clocks” in a network

• Emerging as a preferred synchronization mechanism on networks

Slide 17-1 Copyright © 2004 Pearson Education, Inc. Operating Systems: A Modern Perspective, Chapter 17.

Documents

closef2 slide

server slide

parts slide

modern perspective

operating systems

pearson education

distributed computing

traditional memory interfaces