Performance of Tokenbased Distributed Mutual Exclusion Algorithms Scott

Performance of Tokenbased Distributed Mutual Exclusion Algorithms Scott J. Mc. Callen Kent State University November 28 2006

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

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

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

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

Suzuki-Kasami Results (Low Load)

Suzuki-Kasami Results (High Load)

Raymond Results (Low Load)

Raymond Results (High Load)

Results Summary n Raymond n Low Load n n n High Load n n n Message Complexity : log(n)/log(2) Synchronization Delay : 2*log(n)/log(2) Message Complexity : 4 Synchronization Delay : 2 Suzuki-Kasami n Low Load n n n Message Complexity : N Synchronization Delay : 1 High Load n n Message Complexity : N Synchronization Delay: 1 [not log(n)/2] [not log(n)]

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

Raymond’s Children Experiment Setup n Attributes n n Synchronization Delay Variables n Number of children per node n Range from 1 to 8 (why? ) n Parameters 50 nodes in the network (why? ) n 40 sequential request/releases (low contention) n

Results n Increasing the number of children per node decreases the message complexity

Suzuki-Kasami Average Token Forwarding n n n 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?

Forwarding Experiments Setup n Attributes n n Message Complexity + Token Forwards until CS Variables n Network size n Range from 5 to 30 by 5 n Parameters n Nodes – 1 requests

Suzuki-Kasami Results n Based on the number of nodes in the network, the result is proportional to [(nodes*requests)+sum(1: requests)]/nodes

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

Future Work n Test systems in continuous high-contention n n Test Raymond’s algorithm with random tree n n 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 n n Current experiments are all-request/all-release, continuous highcontention may produce alternate results Perhaps there are tree algorithms which require high-contention critical section access within a small subgraph Implement message piggy-backing as suggested by Raymond n Could reduce costs of duplicate messages for high-contention system, but should not affect low contention

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

Coding the Project n Successes n Algorithms n n Tython scripts n n n Implementation was mostly successful 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 n Utilized to create graphics

References n n n Brewer, E. , Culler, D. , Gay, D. , and Levis, P. , nes. C 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 nes. C 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 tiny. OS applications. In Proceedings of the 1 st international Conference on Embedded Networked Sensor Systems (Los Angeles, California, USA, November 05 - 07, 2003). Sen. Sys '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.