4. Synchronization (2).pdf

DISTRIBUTED SYSTEMS 

Principles and Paradigms 

Second Edition 

ANDREW S. TANENBAUM 

MAARTEN VAN STEEN 

Chapter 6 

Synchronization (2) 

Tanenbaum & Van Steen, Distributed Systems: Principles and Paradigms, 2e, (c) 2007 Prentice-Hall, Inc. All rights reserved. 0-13-239227-5

Plan 

• Clock synchronization in distributed 

systems 

– Physical clocks 

– Logical clocks 

• Ordered multicasting 

– JGroups 

• Mutual exclusion 

• Election 


JGroups 

• Java toolkit for reliable group communication 

– Join group 

– Send to all or single group members 

– Receive messages from group 

Unreliable Reliable 

Unicast UDP TCP 

Multicast IP Multicast JGroups 


JGroups 

• Channels 

– Similar to (BSD) sockets – pullbased 

– Connected to a protocol stack 

• Protocol stack 

– Bidirectional list of protocol 

layers 

• Building blocks for higher-level 

functionality 

– E.g., PullPushAdapter, 

RpcDispatcher 

• Used, e.g., for replication and 

load balancing in a number of 

application servers 

– E.g., JBoss, Tomcat 


Jgroups Programming Basics 

• Processes decide on a 

group name 

• Each process 

1. Creates a channel 

2. Connects to that channel 

• Using the group name 

• This means starting the protocol 

stack 

3. Sends messages to and 

receives messages from the 

channel 

• The concrete multicast depends 

on the protocol stack 

4. Eventually disconnects from 

the channel 

• This means stopping the 

associated protocol stack 


JGroups 

• JGroup’s protocol stack has a number of 

ordering possibilities 

– None 

– org.jgroups.protocols.CAUSAL 

– org.jgroups.protocols.TOTAL 


JGroups: Alphabet Example 

• Stable process group 

• Send parts of alphabet in sequence 

– Initiator 

• Select address of random member in group 

• Multicasts {”A”, } 

– Receivers print ”A”, stores ”A” 

– Receiver with address 

• Select address of random member in group 

• Multicasts {”B”, } 

– And so on... 

• Which ordering do we want 





Create channel 

Connect to group 

Listen to messages 

Listen to group changes 

Send an initial message 

A message contains a source (null), a destination (null), and 

A Serializable object (an array with two values) 

Listen to changes in the view 



Receive a massage 

Unpack letter and handler 

Close connection and terminate 

Find a new handler 

Send off next letter 


JGroups: Stack setup 

Use UDP communication 

Ping via mcast 

Discover 

subgroups 

To make the example more interesting… 

Heartbeat-based failure detection 

Check that FD is correct 

And finally causal multicast… 


Plan 

• Clock synchronization in distributed 

systems 

– Physical clocks 

– Logical clocks 

• Ordered multicasting 

– JGroups 


• Election 


Mutual Exclusion 

• We often want to ensure 

that only one process 

accesses a critical region 

• Requirements: ensure 

– Mutually exclusive access 

– Deadlock freedom 

– Starvation freedom 

– Fairness 

• Types of algorithms 

– Permission-based 

– Token-based 


Mutual Exclusion: 

A Centralized Algorithm 

• Simulate how mutual exclusion is done in a 

one-processor system 

– Let one process act as a coordinator 

– Send request to coordinator to ask for permission 



A Centralized Algorithm 

• Mutually exclusive access 

– Coordinator only lets one process in 

• Deadlock freedom 

– If no process is in critical region, any other 

that wants to can be granted 

• Starvation freedom 

• Fairness 

– Access granted in order of receipt at 

coordinator 

• Only 3 messages per ressource use 

– But coordinator is single point of failure and 

potential bottleneck 



A Decentralized Algorithm 

• Sigma: algorithm based on DHTs 

– Logically replicate ressource to n coordinators 

• Name ith replica ”r_name-i” and let node with id 

lookup(r_name-i) be responsible for it 

– To enter into criticial region 

• Get grant from m > n/2 coordinators 

• If cannot get enough grants, give up and retry later 

– Problem: failure/recovery of coordinator 

• May handle up to f failures where 

– 

• Probability of violating mutual exclusion is small 



A Decentralized Algorithm 


– Average lifetime of node is 10000 seconds 



A Distributed Algorithm 

• Totally ordered multicast of requests for resources from requester to 

receivers 

1. Receiver did not send request: Send OK back 

2. Receiver sent request, is accessing resource: Wait and queue request 

3. Receiver sent request, is not accessing resource 

• Receiver has higher timestamp on its request: Send OK back 

• Receiver has lower timestamp on its: Wait and queue request 

• When requester has OK from all processes it accesses resource 

– When done, send OK to all processes in queue 



A Distributed Algorithm 

• Guarantees 

– Mutual exclusion 

• Need OK from all processes 

– Deadlock freedom 

– Starvation freedom 

– Fairness 

• Timestamp used to decide 

• But 

– n-points-of-failure (instead of 1) 

• Could try to detect whether resource 

has failed 

– n bottlenecks (instead of 1) 

• Could try to just get OK from majority 



A Token Ring Algorithm 

• Assume processes can be connected in a (logical) ring 

– Token circulates on the ring 

– Take the token if need to access critical region 

– If token not needed, send it to next neighbor 



A Token Ring Algorithm 

• Guarantees 

– Only one token at one process in a given time 

• Mutual exclusion, deadlock freedom, starvation freedom, 

fairness 

• But 

– What if token is lost 

– Process crashes 


A Comparison of the Four Algorithms 

• Figure 6-17. A comparison of three mutual 

exclusion algorithms. 


Election 

• There is often a need for selecting a process 

with some special role 

– E.g., choose coordinator in a centralized protocol 

• If processes have unique id 

– Try to find process with highest id, make this leader 

– Algorithms differ in how they locate process with 

highest id 

• If processes do not have unique id (or similar) 

– Then there is no way to select any of them to be 

special 

– Well… 


Population Protocol 

• All agents start in same state 

– Eventually one agent is leader 


JGroups and Election 

• Just use view and choose the first process 

in the view to be elected 


The Bully Algorithm 

• Assume that every process knows the ids of 

every other process 

– Static group, but members may have failed 

• P notices that there is no coordinator – P wants 

to hold an election 

– P sends an ELECTION message to all processes with 

higher numbers 

– If no one responds, P wins the election and becomes 

coordinator 

– If one of the higher-ups answers, it takes over – P’s 

job is done 


The Bully Algorithm (1) 

• Figure 6-20. The bully election algorithm. (a) Process 4 holds 

an election. (b) Processes 5 and 6 respond, telling 4 to stop. (c) 

Now 5 and 6 each hold an election. 


The Bully Algorithm (2) 

• Figure 6-20. The bully election algorithm. (d) Process 6 

tells 5 to stop. (e) Process 6 wins and tells everyone. 


A Ring Algorithm 

• Build view of processes by circulating message 

– Two steps: ELECTION and COORDINATOR 

– ELECTION message constructs view of alive processes during 

circulation 

– Choose process with highest id from view as coordinator 


Elections in Wireless Environments 

• Limited range of wireless 

• May want to elect node with particular 

properties 

– High battery-level 

– Near the “middle” of the network 

– … 

• Assume stability and reliability initially 


Elections in Wireless Environments (1) 

• Figure 6-22. Election algorithm in a wireless network, with node 

a as the source. (a) Initial network. (b)–(e) The build-tree phase 



• Figure 6-22. Election algorithm in a wireless network, 

with node a as the source. (a) Initial network. (b)–(e) The 

build-tree phase 



• Figure 6-22. (e) The build-tree phase. 

(f) Reporting of best node to source. 



• Handling split and merge 

– Use probe/reply messages to see if children in 

spanning tree are gone 

• Handling node crashes and recovery 

– Crash is a special case of split 

– Recovery is treated as a special case of 

merge 


Elections in Large-Scale Systems (1) 

• Requirements for superpeer selection: 

1. Normal nodes should have low-latency 

access to superpeers. 

2. Superpeers should be evenly distributed 

across the overlay network. 

3. There should be a predefined portion of 

superpeers relative to the total number of 

nodes in the overlay network. 

4. Each superpeer should not need to serve 

more than a fixed number of normal nodes. 


Elections in Large-Scale Systems (2) 

• Assume we want L leaders in m-bit Chord 

DHT 

– Reserve don’t care bits 

– p does lookup(p && 11…11000) to detect if it 

is the leader 

k 

• Each super-peer is then responsible for 

with high probability 


Summary 


– Centralized 

– Decentralized 

– Distributed 

– Token-based 

• Election 

– Bully 

– Ring 

– Decentral and large-scale

4. Synchronization (2).pdf

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?