36
Consistency and Replication Chapter 6

Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Embed Size (px)

Citation preview

Page 1: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Consistency and Replication

Chapter 6

Page 2: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Release Consistency (1)

A valid event sequence for release consistency.

Use acquire/release operations to denote critical regions.

Can also use a barrier synchronization.

Page 3: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

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 consistent (sequential consistency is not required).

Page 4: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Release Consistency (3)

• Lazy release consistency – wait until the next process needs the data to send the update

• Eager release consistency – send the update out as soon as it is released by the process using it.

Page 5: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Entry Consistency

• Associate each data variable with a specific synchronization or lock variable

Page 6: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

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 performed until it has performed with respect to that variable's owner.

Page 7: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Entry Consistency (1)

A valid event sequence for entry consistency.

Page 8: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

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.

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

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

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

(b)

Page 9: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Eventual Consistency

The principle of a mobile user accessing different replicas of a distributed database.

Page 10: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Monotonic Reads

If a process reads the value of a data item x, any successive read operation on x by that process will always return that same value or a more recent value.

Page 11: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

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 storeb) A data store that does not provide monotonic reads.

Page 12: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Monotonic Writes

A write operation by a process on a data item x is completed before any successive write operation on x by the same process.

Page 13: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Monotonic Writes

The write operations performed by a single process P at two different local copies of the same data storea) A monotonic-write consistent data store.b) A data store that does not provide monotonic-write consistency.

Page 14: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Read Your Writes

The effect of a write operation by a process on data item x will always be seen by a successive read operation on x by the same process.

Page 15: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Read Your Writes

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

Page 16: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Writes Follow Reads

A write operation by a process on a data item x following a previous read operation on x by the same process, is guaranteed to take place on the same or a more recent value of x that was read.

Page 17: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Writes Follow Reads

a) A writes-follow-reads consistent data storeb) A data store that does not provide writes-follow-reads consistency

Page 18: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Replica Placement

The logical organization of different kinds of copies of a data store into three concentric rings.

Page 19: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Server-Initiated Replicas

Counting access requests from different clients.

Page 20: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Client-Initiated Replicas

• Really the same as client-side caches

• It is also possible to have clients retrieve data from other client caches

• Cache Only Memory Architecture– Used in the KSR supercomputer to construct

distributed shared memory

• Can also dynamically change the size of the cache according to the demand placed on it– Cooperative cache

Page 21: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Update Propagation

Three possibilities:

• Propagate only a notification of an update

• Transfer data from one copy to another

• Propagate the update operation to other copies

Page 22: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Pull versus Push Protocols

Push-based approach• Also called a server-based protocol• Server initiates the transfer without the client

asking for it

Pull-based approach• Transfer happens when the client asks for it

Advantages depend on the type of workload• Amount of data, frequency of update, frequency

of read-only operations

Page 23: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Pull versus Push Protocols

A comparison between push-based and pull-based protocols in the case of multiple client, single server systems.

Issue Push-based Pull-based

State of server List of client replicas and caches None

Messages sent Update (and possibly fetch update later) Poll and update

Response time at client

Immediate (or fetch-update time) Fetch-update time

Page 24: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Lease Protocols

• Have the copy expire after a period of time

• A client can ask to renew a lease

• A short lease can be given for a client than only uses the item infrequently – the server doesn’t have to maintain state for as long

Page 25: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Remote-Write Protocols (1)

Primary-based remote-write protocol with a fixed server to which all read and write operations are forwarded.

Page 26: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Remote-Write Protocols (2)

The principle of primary-backup protocol.

Page 27: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Local-Write Protocols (1)

Primary-based local-write protocol in which a single copy is migrated between processes.

Page 28: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Local-Write Protocols (2)

Primary-backup protocol in which the primary migrates to the process wanting to perform an update.

Page 29: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Active Replication (1)

The problem of replicated invocations.

Page 30: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Active Replication (2)

a) Forwarding an invocation request from a replicated object.b) Returning a reply to a replicated object.

Page 31: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Quorum-Based Protocols

Three examples of the voting algorithm:a) A correct choice of read and write setb) A choice that may lead to write-write conflictsc) A correct choice, known as ROWA (read one, write all)

Page 32: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Orca

A simplified stack object in Orca, with internal data and two operations.

OBJECT IMPLEMENTATION stack; top: integer; # variable indicating the top stack: ARRAY[integer 0..N-1] OF integer # storage for the stack

OPERATION push (item: integer) # function returning nothing BEGIN GUARD top < N DO stack [top] := item; # push item onto the stack top := top + 1; # increment the stack pointer OD; END;

OPERATION pop():integer; # function returning an integer BEGIN GUARD top > 0 DO # suspend if the stack is empty top := top – 1; # decrement the stack pointer RETURN stack [top]; # return the top item OD; END;BEGIN top := 0; # initializationEND;

Page 33: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Management of Shared Objects in Orca

Four cases of a process P performing an operation on an object O in Orca.

Page 34: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Causally-Consistent Lazy Replication

The general organization of a distributed data store. Clients are assumed to also handle consistency-related communication.

Page 35: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Processing Read Operations

Performing a read operation at a local copy.

Page 36: Consistency and Replication Chapter 6. Release Consistency (1) A valid event sequence for release consistency. Use acquire/release operations to denote

Processing Write Operations

Performing a write operation at a local copy.