Lamport Clock

Lamport Clock Companies that have a group of computers connected by an interconnection network will often desire a way to devise an operating system which will (Distributed systems; distributed coordination): Manage the resources of the network as a whole Appear to users as a single operating system or a "virtual uniprocessor." In particular, a company may wish to treat the multiple central processing units (CPUs) as a system resource so that an application can take advantage of available CPU cycles on any machine.

This task is challenged by the lack of shared memory that distinguishes distributed systems from multiprocessor systems. However, processes can communicate by a reliable message protocol and a technique known as a Lamport clock invented in 1978 by Leslie Lamport that can be used to sort a set of distributed system events into a partial order. To understand the Lamport clock technique, it's useful to first review characteristics of a computer clock.

A hardware clock in a computer is a device which generates interrupt signals periodically (Clocks, timestamps and ordering in distributed systems). An interrupt routine increments a time counter which has been initialized by an operator to an initial time that is more than likely different on each computer. And, timers on different computers run at slightly different rates. Thus, ordering events in decentralized systems is complex. It is not possible to accurately order events on different machines using local times.

When synchronizing logical clocks, clocks which are synchronized relatively to each other, Lamport recognized that the actual time is not important. Rather, the ordering of events holds the key to facilitating synchronization (Amir, 1998): If a and b are events in the same process, and an occurs before b then a=> b If a is the event of a message being sent by one process, and b is the event of the message being received by another process then a => b. If a => b then time (a) < time (b).

In simpler terms, processes need to agree on the order in which events occur rather than the time at which they occurred. With respect to clocks, the Lamport technique works as follows (Distributed systems; distributed coordination). Every process/processor maintains its own time. Local events are assigned only increasing time stamps as they occur. And, each message between processes is accompanied by a time stamp indicating the time at the sender. When a message is received, its time stamp is compared with the local time.

Then, if the time stamp is greater than the local time, the local time is set to be equal to the time stamp plus one. In more detail, the Lamport clock is not a total ordering, but it can be made into one by combining the time with the id of the process in which the event occurs (Distributed systems; distributed coordination). The Lamport clock is used in Lamport's mutual exclusion algorithm. It assumes that each processor keeps its own clock value.

Each process participating in the algorithm keeps a queue of pending requests.

The instructions to implement a Lamport clock resembles the following: enterCS: Construct a request-to-enter message; Assign the current logical time to the request; Send the message to each other process; Wait for okay response from each other process; receiveRequestMessage: if this process is in the critical section enqueue the request; else if this process is not waiting to enter the critical section send okay to requestor; else / / this process is waiting to enter the critical section if (this.request.timeStamp < incomingRequest.timeStamp) enqueue the request; else send okay to requestor; exitCS: while (request queue not empty){ dequeue a request message; send okay to requestor; Distributed systems; distributed coordination).

For the Lamport clock technique to work, two requests cannot have the same time stamp. And, all processes must agree on the ordering of the requests (Distributed systems; distributed coordination). The algorithm fails if any of the participating process fails to respond to messages 2(n-1) messages required for each entry into the critical section. Therefore, an often suggested improvement is to require a process to acknowledge every request message with either OKAY or DENY.

By adding this requirement, if a process goes down, the other process will be able to detect it and either remove it from the group or terminate the application. Others suggest appending the process ID or system ID to.