Sistem Terditribusi

(1)

Communication

(2)

Layered Protocols (1)

(3)

Layered Protocols (2)

(4)

Data Link Layer

(5)

Client-Server TCP

a) Normal operation of TCP.

(6)

Middleware Protocols

(7)

Conventional Procedure Call

a) Parameter passing in a local procedure call: the stack before the call to read

(8)

Client and Server Stubs

(9)

Steps of a Remote Procedure Call

1.

Client procedure calls client stub in normal way

2.

Client stub builds message, calls local OS

3.

Client's OS sends message to remote OS

4.

Remote OS gives message to server stub

5.

Server stub unpacks parameters, calls server

6.

Server does work, returns result to the stub

7.

Server stub packs it in message, calls local OS

8.

Server's OS sends message to client's OS

9.

Client's OS gives message to client stub

(10)

Passing Value Parameters (1)

(11)

Passing Value Parameters (2)

a) Original message on the Pentium

b) The message after receipt on the SPARC

(12)

Parameter Specification and Stub Generation

a)

A procedure

(13)

Doors

(14)

Asynchronous RPC (1)

a) The interconnection between client and server in a traditional RPC

(15)

Asynchronous RPC (2)

(16)

Writing a Client and a Server

(17)

Binding a Client to a Server

(18)

Distributed Objects

(19)

Binding a Client to an Object

a) (a) Example with implicit binding using only global references

b) (b) Example with explicit binding using global and local references Distr_object* obj_ref; //Declare a systemwide object reference

obj_ref = …; // Initialize the reference to a distributed object obj_ref-> do_something(); // Implicitly bind and invoke a method

(a)

Distr_object objPref; //Declare a systemwide object reference Local_object* obj_ptr; //Declare a pointer to local objects

obj_ref = …; //Initialize the reference to a distributed object

obj_ptr = bind(obj_ref); //Explicitly bind and obtain a pointer to the local proxy obj_ptr -> do_something(); //Invoke a method on the local proxy

(20)

Parameter Passing

(21)

The DCE Distributed-Object Model

a) Distributed dynamic objects in DCE.

(22)

Persistence and Synchronicity in Communication (1)

General organization of a communication system in which hosts are connected through a network

(23)

(24)

a) Persistent asynchronous communication

(25)

Persistence and Synchronicity in Communication (4)

c) Transient asynchronous communication

(26)

e) Delivery-based transient synchronous communication at message delivery

(27)

Berkeley Sockets (1)

Socket primitives for TCP/IP.

Primitive Meaning

Socket Create a new communication endpoint Bind Attach a local address to a socket

Listen Announce willingness to accept connections Accept Block caller until a connection request arrives Connect Actively attempt to establish a connection Send Send some data over the connection

(28)

Berkeley Sockets (2)

(29)

The Message-Passing Interface (MPI)

Some of the most intuitive message-passing primitives of MPI.

Primitive Meaning

MPI_bsend Append outgoing message to a local send buffer

MPI_send Send a message and wait until copied to local or remote buffer MPI_ssend Send a message and wait until receipt starts

MPI_sendrecv Send a message and wait for reply

MPI_isend Pass reference to outgoing message, and continue

MPI_issend Pass reference to outgoing message, and wait until receipt starts MPI_recv Receive a message; block if there are none

(30)

Message-Queuing Model (1)

(31)

Message-Queuing Model (2)

Basic interface to a queue in a message-queuing system.

Primitive Meaning

Put Append a message to a specified queue

Get Block until the specified queue is nonempty, and remove the first message Poll Check a specified queue for messages, and remove the first. Never block. Notify Install a handler to be called when a message is put into the specified

(32)

General Architecture of a Message-Queuing System (1)

(33)

General Architecture of a Message-Queuing System (2)

(34)

Message Brokers

The general organization of a message broker in a message-queuing system.

(35)

Example: IBM MQSeries

(36)

Channels

Some attributes associated with message channel agents.

Attribute Description

Transport type Determines the transport protocol to be used

FIFO delivery Indicates that messages are to be delivered in the order they are sent Message length Maximum length of a single message

Setup retry

(37)

Message Transfer (1)

[image:37.720.65.672.115.395.2]

(38)

Message Transfer (2)

Primitives available in an IBM MQSeries MQI

Primitive Description

MQopen Open a (possibly remote) queue

MQclose Close a queue

MQput Put a message into an opened queue

(39)

Data Stream (1)

(40)

Data Stream (2)

(41)

Data Stream (3)

(42)

Specifying QoS (1)

A flow specification.

Characteristics of the Input Service Required

•maximum data unit size (bytes)

•Token bucket rate (bytes/sec)

•Toke bucket size (bytes)

•Maximum transmission rate (bytes/sec)

•Loss sensitivity (bytes)

•Loss interval ( sec)

•Burst loss sensitivity (data units)

•Minimum delay noticed ( sec)

•Maximum delay variation ( sec)

(43)

Specifying QoS (2)

(44)

Setting Up a Stream

(45)

Synchronization Mechanisms (1)

(46)

Synchronization Mechanisms (2)

(47)

Processes

(48)

Thread Usage in Nondistributed Systems

(49)

Thread Implementation

(50)

Multithreaded Servers (1)

(51)

Multithreaded Servers (2)

Three ways to construct a server.

Model Characteristics

Threads Parallelism, blocking system calls

Single-threaded process No parallelism, blocking system calls

(52)

The X-Window System

(53)

Client-Side Software for Distribution Transparency

(54)

Servers: General Design Issues

a) Client-to-server binding using a daemon as in DCE

(55)

Object Adapter (1)

Organization of an

object server

(56)

Object Adapter (2)

The header.h file used by the adapter and any program that calls an adapter

.

/* Definitions needed by caller of adapter and adapter */ #define TRUE

#define MAX_DATA 65536

/* Definition of general message format */ struct message {

long source /* senders identity */

long object_id; /* identifier for the requested object */ long method_id; /* identifier for the requested method */ unsigned size; /* total bytes in list of parameters */ char **data; /* parameters as sequence of bytes */ };

/* General definition of operation to be called at skeleton of object */ typedef void (*METHOD_CALL)(unsigned, char* unsigned*, char**);

(57)

Object Adapter (3)

The thread.h file used by the adapter for using threads.

typedef struct thread THREAD; /* hidden definition of a thread */ thread *CREATE_THREAD (void (*body)(long tid), long thread_id);

/* Create a thread by giving a pointer to a function that defines the actual */ /* behavior of the thread, along with a thread identifier */

void get_msg (unsigned *size, char **data);

void put_msg(THREAD *receiver, unsigned size, char **data);

(58)

Object Adapter (4)

The main part of an

adapter that implements a thread-per-object

(59)

Reasons for Migrating Code

(60)

Models for Code Migration

(61)

Migration and Local Resources 1

Three Types of Process-to-resource binding

1. Binding by Identifier (Strongest Binding): Proses memerlukan dengan tepat me-reference resource.

Contoh : proses menggunakan URL untuk merujuk ke web site atau FTP Server pada alamat internet.

2. Binding by Value (Weaker Binding) : Hanya value dari resource yang dibutuhkan. Eksekusi proses tidak berpengaruh jika resource lain

menyediakan value yang sama.

Contoh : Ketika program membutuhkan library standar seperti

pemrograman pada C atau Java. Library tsb biasanya secara lokal ada, biarpun lokasinya pada sistem file lokal berbeda antara site.

3. Binding by Type (Weakest Binding) : Proses membutuhkan hanya tipe tertentu dari resource.

(62)

Migration and Local Resources 2

Three Types of Resource-to machine binding

1. Unattached resources : mudah dipindahkan (move) antar mesin (data atau file yang berasosiasi dengan program).

2. Fastened resource : move (memindahkan) atau copy dapat dilakukan Contoh : database lokal dan web site kesluruhan (web site complete)

3. Fixed resource : bound spesifik mesin atau linkungan dan tidak bisa dipindahkan (move). Fixed resource sering device lokal

(63)

Migration and Local Resources 3

Actions to be taken with respect to the references to local resources when migrating code to another machine.

Unattached Fastened Fixed

By identifier By value By type

MV (or GR) CP ( or MV, GR)

RB (or GR, CP)

GR (or MV) GR (or CP) RB (or GR, CP)

GR GR RB (or GR)

Resource-to machine binding

Process-to-resource

binding

GR : Establish a global Systemwide Reference MV : Move The Resource

CV : Copy The Value of the Resource

(64)

Migration in Heterogeneous Systems

The principle of maintaining a migration stack to support migration of an execution segment in a heterogeneous environment

(65)

Overview of Code Migration in D'Agents (1)

A simple example of a Tel agent in D'Agents submitting a script to a remote machine (adapted from [gray.r95])

proc factorial n {

if ($n 1) { return 1; } # fac(1) = 1

expr $n * [ factorial [expr $n – 1] ] # fac(n) = n * fac(n – 1) }

set number … # tells which factorial to compute

set machine … # identify the target machine

agent_submit $machine –procs factorial –vars number –script {factorial $number }

(66)

Overview of Code Migration in D'Agents (2)

An example of a Tel agent in D'Agents migrating to different machines where it executes the UNIX who command (adapted from [gray.r95])

all_users $machines proc all_users machines {

set list "" # Create an initially empty list

foreach m $machines { # Consider all hosts in the set of given machines agent_jump $m # Jump to each host

set users [exec who] # Execute the who command append list $users # Append the results to the list }

return $list # Return the complete list when done }

set machines … # Initialize the set of machines to jump to set this_machine # Set to the host that starts the agent

# Create a migrating agent by submitting the script to this machine, from where # it will jump to all the others in $machines.

agent_submit $this_machine –procs all_users -vars machines

-script { all_users $machines }

(67)

Implementation Issues (1)

(68)

Implementation Issues (2)

The parts comprising the state of an agent in D'Agents.

Status Description

Global interpreter variables Variables needed by the interpreter of an agent Global system variables Return codes, error codes, error strings, etc. Global program variables User-defined global variables in a program

Procedure definitions Definitions of scripts to be executed by an agent Stack of commands Stack of commands currently being executed

(69)

Software Agents in Distributed Systems

Some important properties by which different types of agents can be distinguished.

Property Common to

all agents? Description

Autonomous Yes Can act on its own

Reactive Yes Responds timely to changes in its environment Proactive Yes Initiates actions that affects its environment

Communicative Yes Can exchange information with users and other agents

Continuous No Has a relatively long lifespan

(70)

Agent Technology

(71)

Agent Communication Languages (1)

Examples of different message types in the FIPA ACL [fipa98-acl], giving the purpose of a message, along with the description of the actual message content.

Message purpose Description Message Content

INFORM Inform that a given proposition is true Proposition QUERY-IF Query whether a given proposition is true Proposition QUERY-REF Query for a give object Expression

CFP Ask for a proposal Proposal specifics PROPOSE Provide a proposal Proposal

ACCEPT-PROPOSAL Tell that a given proposal is accepted Proposal ID REJECT-PROPOSAL Tell that a given proposal is rejected Proposal ID

REQUEST Request that an action be performed Action specification

(72)

Agent Communication Languages (2)

A simple example of a FIPA ACL message sent between two agents using Prolog to express genealogy information.

(73)

Naming

(74)

Name Spaces (1)

(75)

Name Spaces (2)

The general organization of the UNIX file system

(76)

Linking and Mounting (1)

(77)

Linking and Mounting (2)

(78)

Linking and Mounting (3)

(79)

Name Space Distribution (1)

(80)

Name Space Distribution (2)

A comparison between name servers for implementing nodes from a large-scale name space partitioned into a global layer, as an

administrational layer, and a managerial layer.

Item Global Administrational Managerial

Geographical scale of network Worldwide Organization Department Total number of nodes Few Many Vast numbers Responsiveness to lookups Seconds Milliseconds Immediate Update propagation Lazy Immediate Immediate Number of replicas Many None or few None

(81)

Implementation of Name Resolution (1)

(82)

Implementation of Name Resolution (2)

(83)

Implementation of Name Resolution (3)

Recursive name resolution of <nl, vu, cs, ftp>. Name servers cache intermediate results for subsequent lookups.

Server for node

Should

resolve Looks up

Passes to child Receives and caches Returns to requester

cs <ftp> #<ftp> -- -- #<ftp> vu <cs,ftp> #<cs> <ftp> #<ftp> #<cs>

#<cs, ftp>

ni <vu,cs,ftp> #<vu> <cs,ftp> #<cs> #<cs,ftp>

#<vu> #<vu,cs> #<vu,cs,ftp> root <ni,vu,cs,ftp> #<nl> <vu,cs,ftp> #<vu>

(84)

Implementation of Name Resolution (4)

(85)

The DNS Name Space

The most important types of resource records forming the

contents of nodes in the DNS name space.

Type of record

Associated

entity Description

SOA Zone Holds information on the represented zone

A Host Contains an IP address of the host this node represents

MX Domain Refers to a mail server to handle mail addressed to this node SRV Domain Refers to a server handling a specific service

NS Zone Refers to a name server that implements the represented zone CNAME Node Symbolic link with the primary name of the represented node PTR Host Contains the canonical name of a host

HINFO Host Holds information on the host this node represents

(86)

DNS Implementation (1)

An excerpt

from the

DNS

database

for the

zone

(87)

DNS Implementation (2)

Part of the description for the

vu.nl

domain

which contains the

cs.vu.nl

domain.

Name Record type Record value

cs.vu.nl NIS solo.cs.vu.nl

(88)

The X.500 Name Space (1)

A simple example of a X.500 directory entry using X.500 naming conventions.

Attribute Abbr. Value

Country C NL

Locality L Amsterdam

Organization L Vrije Universiteit

OrganizationalUnit OU Math. & Comp. Sc.

CommonName CN Main server

Mail_Servers -- 130.37.24.6, 192.31.231,192.31.231.66

FTP_Server -- 130.37.21.11

(89)

The X.500 Name Space (2)

(90)

The X.500 Name Space (3)

Two directory entries having

Host_Name

as RDN.

Attribute Value Attribute Value

Country NL Country NL

Locality Amsterdam Locality Amsterdam Organization Vrije Universiteit Organization Vrije Universiteit

OrganizationalUnit Math. & Comp. Sc. OrganizationalUnit Math. & Comp. Sc.

CommonName Main server CommonName Main server

Host_Name star Host_Name zephyr

(91)

Naming versus Locating Entities

a) Direct, single level mapping between names and addresses.

(92)

Forwarding Pointers (1)

(93)

Forwarding Pointers (2)

(94)

Home-Based Approaches

(95)

Hierarchical Approaches (1)

(96)

(97)

(98)

a) An insert request is forwarded to the first node that knows about entity E.

(99)

Pointer Caches (1)

(100)

Pointer Caches (2)

(101)

Scalability Issues

The scalability issues related to uniformly placing subnodes of a

(102)

The Problem of Unreferenced Objects

(103)

Reference Counting (1)

(104)

Reference Counting (2)

a)

Copying a reference to another process

and incrementing the counter too late

(105)

Advanced Referencing Counting (1)

a) The initial assignment of weights in weighted reference counting

(106)

Advanced Referencing Counting (2)

(107)

(108)

(109)

Tracing in Groups (1)

(110)

(111)

(112)

Synchronization

(113)

Clock Synchronization

(114)

Physical Clocks (1)

(115)

Physical Clocks (2)

TAI seconds are of constant length, unlike solar seconds. Leap seconds are introduced when

(116)

Clock Synchronization Algorithms

(117)

Cristian's Algorithm

(118)

The Berkeley Algorithm

a) The time daemon asks all the other machines for their clock values

b) The machines answer

(119)

Lamport Timestamps

a) Three processes, each with its own clock. The clocks run at different rates.

(120)

Example: Totally-Ordered Multicasting

(121)

Global State (1)

a)

A consistent cut

(122)

Global State (2)

(123)

Global State (3)

b) Process Q receives a marker for the first time and records its local state

c) Q records all incoming message

(124)

The Bully Algorithm (1)

The bully election algorithm

• Process 4 holds an election

(125)

Global State (3)

d) Process 6 tells 5 to stop

(126)

A Ring Algorithm

(127)

Mutual Exclusion:

A Centralized Algorithm

a) Process 1 asks the coordinator for permission to enter a critical region. Permission is granted

b) Process 2 then asks permission to enter the same critical region. The coordinator does not reply.

(128)

A Distributed Algorithm

a) Two processes want to enter the same critical region at the same moment.

b) Process 0 has the lowest timestamp, so it wins.

(129)

A Toke Ring Algorithm

a)

An unordered group of processes on a network.

(130)

Comparison

A comparison of three mutual exclusion algorithms.

Algorithm Messages per entry/exit

Delay before entry

(in message times) Problems

Centralized 3 2 Coordinator crash

Distributed 2 ( n – 1 ) 2 ( n – 1 ) Crash of any process

(131)

The Transaction Model (1)

(132)

The Transaction Model (2)

Examples of primitives for transactions.

Primitive Description

BEGIN_TRANSACTION Make the start of a transaction

END_TRANSACTION Terminate the transaction and try to commit

ABORT_TRANSACTION Kill the transaction and restore the old values

READ Read data from a file, a table, or otherwise

(133)

The Transaction Model (3)

a) Transaction to reserve three flights commits

b) Transaction aborts when third flight is unavailable BEGIN_TRANSACTION

reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi; END_TRANSACTION

(a)

BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi;

reserve Nairobi -> Malindi full => ABORT_TRANSACTION

(134)

Distributed Transactions

a) A nested transaction

(135)

Private Workspace

a) The file index and disk blocks for a three-block file

b) The situation after a transaction has modified block 0 and appended block 3

(136)

Writeahead Log

a) A transaction

b) – d) The log before each statement is executed

x = 0; y = 0;

BEGIN_TRANSACTION; x = x + 1;

y = y + 2 x = y * y;

END_TRANSACTION; (a)

Log

[x = 0 / 1]

(b)

Log

[x = 0 / 1] [y = 0/2]

(c)

Log

[x = 0 / 1] [y = 0/2] [x = 1/4]

(137)

Concurrency Control (1)

(138)

Concurrency Control (2)

(139)

Serializability

a)

–

c)

Three transactions T

₁

, T

₂

, and T

₃

d)

Possible schedules

BEGIN_TRANSACTION x = 0;

x = x + 1;

END_TRANSACTION

(a)

x = x + 2;

END_TRANSACTION

(b)

x = x + 3;

END_TRANSACTION

(c)

Schedule 1 x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3 Legal Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; Legal Schedule 3 x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3; Illegal

(140)

Two-Phase Locking (1)

(141)

Two-Phase Locking (2)

(142)

Pessimistic Timestamp Ordering

(143)

Synchronization

(144)

Clock Synchronization

(145)

Physical Clocks (1)

(146)

Physical Clocks (2)

TAI seconds are of constant length, unlike solar seconds. Leap seconds are introduced when

(147)

Clock Synchronization Algorithms

(148)

Cristian's Algorithm

(149)

The Berkeley Algorithm

a) The time daemon asks all the other machines for their clock values

b) The machines answer

(150)

Lamport Timestamps

a) Three processes, each with its own clock. The clocks run at different rates.

(151)

Example: Totally-Ordered Multicasting

(152)

Global State (1)

a)

A consistent cut

(153)

Global State (2)

(154)

Global State (3)

b) Process Q receives a marker for the first time and records its local state

c) Q records all incoming message

(155)

The Bully Algorithm (1)

The bully election algorithm

• Process 4 holds an election

(156)

Global State (3)

d) Process 6 tells 5 to stop

(157)

A Ring Algorithm

(158)

Mutual Exclusion:

A Centralized Algorithm

a) Process 1 asks the coordinator for permission to enter a critical region. Permission is granted

b) Process 2 then asks permission to enter the same critical region. The coordinator does not reply.

(159)

A Distributed Algorithm

a) Two processes want to enter the same critical region at the same moment.

b) Process 0 has the lowest timestamp, so it wins.

(160)

A Toke Ring Algorithm

a)

An unordered group of processes on a network.

(161)

Comparison

A comparison of three mutual exclusion algorithms.

Algorithm Messages per entry/exit

Delay before entry

(in message times) Problems

Centralized 3 2 Coordinator crash

Distributed 2 ( n – 1 ) 2 ( n – 1 ) Crash of any process

(162)

The Transaction Model (1)

(163)

The Transaction Model (2)

Examples of primitives for transactions.

Primitive Description

BEGIN_TRANSACTION Make the start of a transaction

END_TRANSACTION Terminate the transaction and try to commit

ABORT_TRANSACTION Kill the transaction and restore the old values

READ Read data from a file, a table, or otherwise

(164)

The Transaction Model (3)

a) Transaction to reserve three flights commits

b) Transaction aborts when third flight is unavailable BEGIN_TRANSACTION

reserve WP -> JFK; reserve JFK -> Nairobi; reserve Nairobi -> Malindi; END_TRANSACTION

(a)

BEGIN_TRANSACTION reserve WP -> JFK; reserve JFK -> Nairobi;

reserve Nairobi -> Malindi full => ABORT_TRANSACTION

(165)

Distributed Transactions

a) A nested transaction

(166)

Private Workspace

a) The file index and disk blocks for a three-block file

b) The situation after a transaction has modified block 0 and appended block 3

(167)

Writeahead Log

a) A transaction

b) – d) The log before each statement is executed

x = 0; y = 0;

BEGIN_TRANSACTION; x = x + 1;

y = y + 2 x = y * y;

END_TRANSACTION; (a)

Log

[x = 0 / 1]

(b)

Log

[x = 0 / 1] [y = 0/2]

(c)

Log

[x = 0 / 1] [y = 0/2] [x = 1/4]

(168)

Concurrency Control (1)

(169)

Concurrency Control (2)

(170)

Serializability

a)

–

c)

Three transactions T

₁

, T

₂

, and T

₃

d)

Possible schedules

x = x + 1;

END_TRANSACTION

(a)

x = x + 2;

END_TRANSACTION

(b)

x = x + 3;

END_TRANSACTION

(c)

Schedule 1 x = 0; x = x + 1; x = 0; x = x + 2; x = 0; x = x + 3 Legal Schedule 2 x = 0; x = 0; x = x + 1; x = x + 2; x = 0; x = x + 3; Legal Schedule 3 x = 0; x = 0; x = x + 1; x = 0; x = x + 2; x = x + 3; Illegal

(171)

Two-Phase Locking (1)

(172)

Two-Phase Locking (2)

(173)

Consistency and Replication

(174)

Object Replication (1)

(175)

a) A remote object capable of handling concurrent invocations on its own.

(176)

a) A distributed system for replication-aware distributed objects.

(177)

Data-Centric Consistency Models

(178)

Strict Consistency

Behavior of two processes, operating on the same data item. • A strictly consistent store.

(179)

Linearizability and Sequential Consistency (1)

a) A sequentially consistent data store.

(180)

Linearizability and Sequential Consistency (2)

Three concurrently executing processes.

Process P1 Process P2 Process P3

x = 1;

print ( y, z);

y = 1;

print (x, z);

z = 1;

(181)

Linearizability and Sequential Consistency (3)

Four valid execution sequences for the processes of the

previous slide. The vertical axis is time.

x = 1;

print ((y, z); y = 1;

print (x, z); z = 1;

print (x, y);

Prints: 001011

Signature: 001011

(a)

x = 1; y = 1;

print (x,z); print(y, z); z = 1;

print (x, y);

Prints: 101011

Signature: 101011

(b)

y = 1; z = 1;

print (x, y); print (x, z); x = 1;

print (y, z);

Prints: 010111

Signature: 110101

(c)

y = 1; x = 1; z = 1;

print (x, z); print (y, z); print (x, y);

Prints: 111111

Signature: 111111

(182)

Casual Consistency (1)

Necessary condition:

Writes that are potentially casually

related must be seen by all processes

in the same order. Concurrent

(183)

(184)

a) A violation of a casually-consistent store.

(185)

FIFO Consistency (1)

Necessary Condition:

Writes done by a single process are seen

by all other processes in the order in

which they were issued, but writes from

different processes may be seen in a

(186)

(187)

Statement execution as seen by the three processes from the previous slide. The statements in bold are the ones that generate the output shown.

x = 1;

print (y, z);

y = 1;

print(x, z); z = 1;

print (x, y);

Prints: 00

(a)

x = 1; y = 1;

print(x, z);

print ( y, z); z = 1;

print (x, y);

Prints: 10

(b)

y = 1;

print (x, z); z = 1;

print (x, y);

x = 1;

print (y, z);

Prints: 01

(188)

FIFO Consistency (4)

Two concurrent processes

.

Process P1 Process P2

x = 1;

if (y == 0) kill (P2);

y = 1;

(189)

Weak Consistency (1)

Properties:

•

Accesses to synchronization variables

associated with a data store are sequentially

consistent

•

No operation on a synchronization variable is

allowed to be performed until all previous

writes have been completed everywhere

(190)

Weak Consistency (2)

A program fragment in which some variables may be kept in registers.

int a, b, c, d, e, x, y; /* variables */

int *p, *q; /* pointers */

int f( int *p, int *q); /* function prototype */

a = x * x; /* a stored in register */

b = y * y; /* b as well */

c = a*a*a + b*b + a * b; /* used later */

d = a * a * c; /* used later */

p = &a; /* p gets address of a */

q = &b /* q gets address of b */

(191)

Weak Consistency (3)

a)

A valid sequence of events for weak

consistency.

(192)

Release Consistency (1)

(193)

Release Consistency (2)

Rules:

•

Before a read or write operation on shared data

is performed, all previous acquires done by the

process must have completed successfully.

•

Before a release is allowed to be performed, all

previous reads and writes by the process must

have completed

•

Accesses to synchronization variables are FIFO

(194)

Entry Consistency (1)

Conditions:

• An acquire access of a synchronization variable is not allowed to perform with respect to a process until all updates to the

guarded shared data have been performed with respect to that process.

• Before an exclusive mode access to a synchronization variable by a process is allowed to perform with respect to that process, no other process may hold the synchronization variable, not even in nonexclusive mode.

• After an exclusive mode access to a synchronization variable has been performed, any other process's next nonexclusive mode access to that synchronization variable may not be

(195)

Entry Consistency (1)

(196)

Summary of Consistency Models

a) Consistency models not using synchronization operations.

b) Models with synchronization operations.

Consistency Description

Strict Absolute time ordering of all shared accesses matters.

Linearizability All processes must see all shared accesses in the same order. Accesses are furthermore ordered according to a (nonunique) global timestamp

Sequential All processes see all shared accesses in the same order. Accesses are not ordered in time

Causal All processes see causally-related shared accesses in the same order.

FIFO All processes see writes from each other in the order they were used. Writes from different processes may not always be seen in that order

(a)

Consistency Description

Weak Shared data can be counted on to be consistent only after a synchronization is done Release Shared data are made consistent when a critical region is exited

Entry Shared data pertaining to a critical region are made consistent when a critical region is entered.

(197)

Eventual Consistency

(198)

Monotonic Reads

The read operations performed by a single process P at two different local copies of the same data store.

a) A monotonic-read consistent data store

(199)

Monotonic Writes

The write operations performed by a single process P at two different local copies of the same data store

a) A monotonic-write consistent data store.

(200)

Read Your Writes

a) A data store that provides read-your-writes consistency.