Performance of Tokenbased Distributed Mutual Exclusion Algorithms

1
Performance of Token-based Distributed Mutual
Exclusion Algorithms

• Scott J. McCallen
• Kent State University
• November 28 2006

2
Token-based Algorithms

• A single token circulates through the system
• A process wants to enter CS, it requests token
• A process gets the token, it can enter CS (in
  general)
• Message Types
• Token
• Request

3
Raymonds Token DMX

• Based on a tree structure
• Each node holds a pointer to a node that either
  holds the token or points to where the token is
• A request is held locally and is sent through the
  tree until it reaches the token
• Token traverses the request path until it reaches
  the requester

4
Suzuki-Kasami Token DMX

• Fully connected network
• Requester broadcasts requests to all other nodes
  with sequence number of request
• Before sending the token, holder calculates which
  requests have not been satisfied and enters those
  into the token request queue
• Send token to the request at the top of the queue

5
Initial Verification ExperimentsSetup

• Done to ensure correctness and begin
  experimentation
• Attributes
• Synchronization Delay
• Number of messages between each CS entry
• Message Complexity
• Total number of messages per CS entry
• Variables
• Network size
• Range from 5 to 30 for Suzuki-Kasami (why?)
• Range from 5 to 60 for Raymond (why?)
• Contention level
• low (sequential request/release) and high (all
  request/all release)

6
Suzuki-Kasami Results (Low Load)
7
Suzuki-Kasami Results (High Load)
8
Raymond Results (Low Load)
9
Raymond Results (High Load)
10
Results Summary

• Raymond
• Low Load
• Message Complexity log(n)/log(2)
  not log(n)/2
• Synchronization Delay 2log(n)/log(2)
  not log(n)
• High Load
• Message Complexity 4
• Synchronization Delay 2
• Suzuki-Kasami
• Low Load
• Message Complexity N
• Synchronization Delay 1
• High Load
• Message Complexity N
• Synchronization Delay 1

11
Raymonds Children

• Message Complexity in low load was shown to be
  similar to log(n)/log(2)
• In initial experiments, each node had at most 2
  children
• How does the number of children affect the
  synchronization delay for Raymonds DMX?

12
Raymonds Children ExperimentSetup

• Attributes
• Synchronization Delay
• Variables
• Number of children per node
• Range from 1 to 8 (why?)
• Parameters
• 50 nodes in the network (why?)
• 40 sequential request/releases (low contention)

13
Results

• Increasing the number of children per node
  decreases the message complexity

14
Suzuki-Kasami Average Token Forwarding

• In high contention, nodes are put on the queue
  based on node identification
• A token is then released to the top request on
  the queue
• What happens when a node has the last request and
  what is the average of message complexity and
  number of token forwards before CS is allow?

15
Forwarding ExperimentsSetup

• Attributes
• Message Complexity Token Forwards until CS
• Variables
• Network size
• Range from 5 to 30 by 5
• Parameters
• Nodes 1 requests

16
Suzuki-Kasami Results

• Based on the number of nodes in the network, the
  result is proportional to (nodesrequests)sum(1
  requests)/nodes

17
Conclusions

• Raymond
• Better performance with many children
• Log(n)/log(c) message complexity and sync delay
• Suzuki Kasami
• Very low sync delay
• Steady increase in total token forwards for high
  contention system
• Neither algorithm guarantees granting CS in
  timestamp order

18
Future Work

• Test systems in continuous high-contention
• Current experiments are all-request/all-release,
  continuous high-contention may produce alternate
  results
• Test Raymonds algorithm with random tree
• It may not be possible to create a tree with
  specific children count, what results will be
  produced in the random case
• Test algorithms in a real (non-random) situation
• Perhaps there are tree algorithms which require
  high-contention critical section access within a
  small subgraph
• Implement message piggy-backing as suggested by
  Raymond
• Could reduce costs of duplicate messages for
  high-contention system, but should not affect low
  contention

19
Coding the Project

• Problems
• Message Size
• Limited the number of nodes for Suzuki-Kasami
• Request Queue
• Incrementing length
• Added methods to check contents of queue
• copyTokenToOut didnt copy all information
• Knowing which node had the token
• Required sending messages to all nodes to release
• Token loss
• Token was lost in some tests making that test
  erroneous
• No token loss check algorithm in place for these
  tests

20
Coding the Project

• Successes
• Algorithms
• Implementation was mostly successful
• Tython scripts
• Learning Python rather quickly
• Scripts can run arbitrary number of trials
• Outputting results to file for access later
• Scripts can be ran unattended (except changing
  network size)
• MATLAB
• Utilized to create graphics

21
References

• Brewer, E., Culler, D., Gay, D., and Levis, P.,
  nesC 1.1 Language Reference Manual,
  www.tinyos.net/tinyos-1.x/doc/nesc/ref.pdf, May
  2003.
• Gay, D., Levis, P., von Behren, R., Welsh, M.,
  Brewer, E., and Culler, D. 2003. The nesC
  language A holistic approach to networked
  embedded systems. SIGPLAN Not. 38, 5 (May. 2003),
  1-11.
• Hill, J., Szewczyk, R., Woo, A., Hollar, S.,
  Culler, D., and Pister, K. 2000. System
  architecture directions for networked sensors.
  SIGOPS Oper. Syst. Rev. 34, 5 (Dec. 2000),
  93-104.
• Levis, P., Lee, N., Welsh, M., and Culler, D.
  2003. TOSSIM accurate and scalable simulation of
  entire tinyOS applications. In Proceedings of the
  1st international Conference on Embedded
  Networked Sensor Systems (Los Angeles,
  California, USA, November 05 - 07, 2003). SenSys
  '03. ACM Press, New York, NY, 126-137.
• Raymond, K. 1989. A tree-based algorithm for
  distributed mutual exclusion. ACM Trans. Comput.
  Syst. 7, 1 (Jan. 1989), 61-77.
• Suzuki, I. and Kasami, T. 1985. A distributed
  mutual exclusion algorithm. ACM Trans. Comput.
  Syst. 3, 4 (Nov. 1985), 344-349.