Lec10 - ECE151 Lecture 10 Chapter 6 Consistency and...

Info iconThis preview shows pages 1–7. Sign up to view the full content.

View Full Document Right Arrow Icon
ECE151 – Lecture 10 1 ECE151 – Lecture 10 Chapter 6 Consistency and Replication
Background image of page 1

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
ECE151 – Lecture 10 2 (b) Shared data pertaining to a critical region are made consistent when a critical region is entered. Entry Shared data are made consistent when a critical region is exited Release Shared data can be counted on to be consistent only after a synchronization is done Weak Description Consistency (a) 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 FIFO All processes see causally-related shared accesses in the same order. Causal All processes see all shared accesses in the same order. Accesses are not ordered in time Sequential All processes must see all shared accesses in the same order. Accesses are furthermore ordered according to a (nonunique) global timestamp Linearizability Absolute time ordering of all shared accesses matters. Strict Description Consistency Summary of Consistency Models a) Consistency models not using synchronization operations. b) Models with synchronization operations.
Background image of page 2
ECE151 – Lecture 10 3 Client-Centric Consistency Models Goal: Show how we can perhaps avoid systemwide consistency, by concentrating on what specific clients want, instead of what should be maintained by servers. Background: Most large-scale distributed systems (i.e., databases) apply replication for scalability, but can support only weak consistency: DNS: Updates are propagated slowly, and inserts may not be immediately visible. NEWS: Articles and reactions are pushed and pulled throughout the Internet, such that reactions might be seen before postings. Lotus Notes: Geographically dispersed servers replicate documents, but make no attempt to keep (concurrent) updates mutually consistent. WWW: Caches all over the place, but there need be no guarantee that you are reading the most recent version of a page.
Background image of page 3

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
ECE151 – Lecture 10 4 Consistency for Mobile Users Example: Consider a distributed database to which you have access through your notebook. Assume your notebook acts as a front end to the database. At location A you access the database doing reads and updates. At location B you continue your work, but unless you access the same server as the one at location A , you may detect inconsistencies: your updates at A may not have yet been propagated to B you may be reading newer entries than the ones available at A your updates at B may eventually conflict with those at A Note: The only thing you really want is that the entries you updated and/or read at A , are in B the way you left them in A . In that case, the database will appear to be consistent to you .
Background image of page 4
ECE151 – Lecture 10 5 Eventual Consistency The principle of a mobile user accessing different replicas of a distributed database.
Background image of page 5

Info iconThis preview has intentionally blurred sections. Sign up to view the full version.

View Full DocumentRight Arrow Icon
ECE151 – Lecture 10 6 Monotonic Reads Notation: WS ( x i [ t ]) is the set of write operations (at L i ) that lead to version x i of x (at time t ); WS ( x i [ t 1 ]; x
Background image of page 6
Image of page 7
This is the end of the preview. Sign up to access the rest of the document.

Page1 / 37

Lec10 - ECE151 Lecture 10 Chapter 6 Consistency and...

This preview shows document pages 1 - 7. Sign up to view the full document.

View Full Document Right Arrow Icon
Ask a homework question - tutors are online