Distributed Coordination - Operating Systems, Distributed Computation - Lecture Slides, Slides of Operating Systems

Download Distributed Coordination - Operating Systems, Distributed Computation - Lecture Slides and more Slides Operating Systems in PDF only on Docsity!

18: Distributed Coordination 1

OPERATING SYSTEMS

Distributed Coordination

18: Distributed Coordination 2

DISTRIBUTED COORDINATION

Topics:

• Event Ordering
• Mutual Exclusion
• Atomicity
• Concurrency Control
• Deadlock Handling
• Election Algorithms
• Reaching Agreement

18: Distributed Coordination 4

COORDINATION

"Happening before" vs. concurrent.

• Here A --> B means A occurred before B and thus could have caused B.
• Of the events shown on the next page, which are happened-before and which are concurrent?
• Ordering is easy if the systems share a common clock ( i.e., it's in a centralized system.)
• With no common clock, each process keeps a logical clock.
• This Logical Clock can be simply a counter - it may have no relation to real time.
• Adjust the clock if messages are received with time higher than current time.
• We require that LC( A ) < LC( B ), the time of transmission be less than the time of receipt for a message.
• So if on message receipt, LC( A ) >= LC( B ),

then set LC( B ) = LC( A ) + 1.

Event Ordering

18: Distributed Coordination 5

COORDINATION

Event Ordering

P 0

P 1

P 4

P 3

P 2

P

o

o

o

o

o

Q 0

Q 1

Q 4

Q 3

Q 2

Q

o

o

o

o

o

R 0

R 1

R 4

R 3

R 2

R

o

o

o

o

o

Time

18: Distributed Coordination 7

DISTRIBUTED COORDINATION

CENTRALIZED APPROACH

• Choose one processor as coordinator who handles all requests.
• A process that wants to enter its critical section sends a request message to the coordinator.
• On getting a request, the coordinator doesn't answer until the critical section is empty (has been released by whoever is holding it).
• On getting a release, the coordinator answers the next outstanding request.
• If coordinator dies, elect a new one who recreates the request list by polling all systems to find out what resource each thinks it has.
• Requires three messages per critical section entry;

request, reply, release.

• The method is free from starvation.

Mutual Exclusion/

Synchronization

18: Distributed Coordination 8

COORDINATION

FULLY DISTRIBUTED APPROACH

Approach due to Lamport. These are the general properties for the method:

a) The general mechanism is for a process P[i] to send a request ( with ID and time stamp ) to all other processes.

b) When a process P[j] receives such a request, it may reply immediately or it may defer sending a reply back.

c) When responses are received from all processes, then P[i] can enter its Critical Section.

d) When P[i] exits its critical section, the process sends reply messages to all its deferred requests.

Mutual Exclusion/

Synchronization

18: Distributed Coordination 10

COORDINATION

The Fully Distributed Approach assures:

a) Mutual exclusion b) Freedom from deadlock c) Freedom from starvation, since entry to the critical section is scheduled according to the timestamp ordering. The timestamp ordering ensures that processes are served in a first-come, first-served order. d) 2 X ( n - 1 ) messages needed for each entry. This is the minimum number of required messages per critical-section entry when processes act independently and concurrently.

Problems with the method include:

a) Need to know identity of everyone in system. b) Fails if anyone dies - must continually monitor the state of all processes. c) Processes are always coming and going so it's hard to maintain current data.

Mutual Exclusion/

Synchronization

18: Distributed Coordination 11

COORDINATION

TOKEN PASSING APPROACH

Tokens with rings

• Whoever holds the token can use the critical section. When done, pass on the token. Processes must be logically connected in a ring -- it may not be a physical ring.
• Advantages:

No starvation if the ring is unidirectional.

There are many messages passed per section entered if few users want to get in section.

Only one message/entry if everyone wants to get in.

• OK if you can detect loss of token and regenerate via election or other means.
• If a process is lost, a new logical ring must be generated.

Mutual Exclusion/

Synchronization

18: Distributed Coordination 13

• Atomicity means either ALL the operations associated with a program unit are executed to completion, or none are performed.
• Ensuring atomicity in a distributed system requires a transaction coordinator, which is responsible for the following:

Starting the execution of a transaction.

Breaking the transaction into a number of sub transactions, and distributing these sub transactions to the appropriate sites for execution.

Coordinating the termination of the transaction, which may result in the transaction being committed at all sites or aborted at all sites.

COORDINATION

Atomicity

18: Distributed Coordination 14

Two-Phase Commit Protocol (2PC)

• For atomicity to be ensured, all the sites in which a transaction T executes must agree on the final outcome of the execution. 2PC is one way of doing this.
• Execution of the protocol is initiated by the coordinator after the last step of the transaction has been reached.
• When the protocol is initiated, the transaction may still be executing at some of the local sites.
• The protocol involves all the local sites at which the transaction executed.
• Let T be a transaction initiated at site Si, and let the transaction coordinator at Si be Ci

COORDINATION

Atomicity

18: Distributed Coordination 16

Two-Phase Commit Protocol (2PC)

Phase 2: Recording the decision in the database

• Coordinator adds a decision record ( or ) to its log and forces record onto stable storage.
• Once that record reaches stable storage it is irrevocable (even if failures occur).
• Coordinator sends a message to each participant informing it of the decision (commit or abort).
• Participants take appropriate action locally.

COORDINATION

Atomicity

18: Distributed Coordination 17

Failure Handling in Two-Phase Commit:

Failure of a participating Site:

• The log contains a record. In this case, the site executes redo (T)
• The log contains an record. In this case, the site executes undo (T)
• The log contains a record; consult Ci. If Ci is down, site sends query- status(T) message to the other sites.
• The log contains no control records concerning (T). Then the site executes undo(T).

Failure of the Coordinator Ci:

• If an active site contains a record in its log, then T must be committed.
• If an active site contains an record in its log, then T must be aborted.
• If some active site does not contain the record in its log, then the failed

coordinator Ci cannot have decided to commit T. Rather than wait for Ci to recover, it is preferable to abort T.

• All active sites have a record in their logs, but no additional control records. In

this case we must wait for the coordinator to recover. Blocking problem - T is blocked pending the recovery of site Si.

COORDINATION

Atomicity

18: Distributed Coordination 19

Locking Protocols == Single-coordinator approach:

• A single lock manager resides in a single chosen site; all lock and unlock requests are made

at that site.

• Simple implementation
• Simple deadlock handling
• Possibility of bottleneck
• Vulnerable to loss of concurrency controller if single site fails.

COORDINATION

Concurrency Control

18: Distributed Coordination 20

Locking Protocols == Multiple-coordinator approach:

Distributes lock-manager function over several sites.

Majority protocol:

• Avoids drawbacks of central control by replicating data in a decentralized manner.
• More complicated to implement.
• Deadlock-handling algorithms must be modified; possible for deadlock to occur in locking

only one data item.

Biased protocol:

• Like majority protocol, but requests for shared locks prioritized over exclusive locks.
• Less overhead on reads than in majority protocol; but more overhead on writes.
• Like majority protocol, deadlock handling is complex.

COORDINATION

Concurrency Control