Mobile Objects Navigating a Network
5.1 Mobile Object in a Process Graph .1 Problem Definition.1 Problem Definition
A mobile object is an object (such as a file or a data structure) that can be accessed sequentially by different processes. Hence, a mobile object is a concurrent object that moves from process to process in a network of processes.
When a process momentarily owns a mobile object, the process can use the ob-ject as if it was its only user. It is assumed that, after using a mobile obob-ject, a pro-cess eventually releases it, in order that the object can move to another propro-cess that requires it. So what has to be defined is a navigation service that provides the pro-cesses with two operations denotedacquire_object()andrelease_object()such that any use of the object by a processpi is bracketed by an invocation to each of these operations, namely
acquire_object(); use of the object bypi; release_object().
As already noticed, in order that the state of the object remains always consistent, it is required that the object be accessed by a single process at a time, and the object has to be live in the sense that any process must be able to obtain the mobile object.
This is captured by the two classical safety and liveness properties which instantiate as follows for this problem (where the sentences “the object belongs to a process”
M. Raynal, Distributed Algorithms for Message-Passing Systems,
DOI10.1007/978-3-642-38123-2_5, © Springer-Verlag Berlin Heidelberg 2013
93
or “a process owns the object” means that the object is currently located at this process):
• Safety: At any time, the object belongs to at most one process.
• Liveness: Any process that invokes acquire_object() eventually becomes the owner of the object.
Let us notice that a processpi invokesrelease_object()after having obtained and used the object. Hence, it needs to invoke againacquire_object()if it wants to use the mobile object again.
5.1.2 Mobile Object Versus Mutual Exclusion
The particular case where the ownership of the mobile object gives its owner a particular right (e.g., access to a resource) is nothing more than an instance of the mutual exclusion problem. In that case, the mobile object is a stateless object, which is usually called a token. The process that has the token can access the resource, while the other processes cannot. Moreover, any process can require the token in order to be eventually granted the resource.
Token-based mutual exclusion algorithms define a family of distributed mutual exclusion algorithms. We will see in Chap.10another family of distributed mutual exclusion algorithms, which are called permission-based algorithms.
5.1.3 A Centralized (Home-Based) Algorithm
A simple solution to the navigation of a mobile object consists in using a home-based structure by statically associating a fixed processp with the mobile object.
Such a home-based scheme is easy to implement. When it is not used, the object resides at its home processp, and a three-way handshake algorithm is used to ensure that any process that invokesacquire_object()eventually obtains the object.
Three-Way Handshake Algorithm The three-way handshake algorithm works as follows. Its name comes from the three messages used to satisfy an object request.
• When a processpi invokesacquire_object(),pi sends a messageREQUEST(i)to the home processp, and waits for the object.
• When the home process receives a messageREQUEST(i)from a process pi, it adds this message in a local queue and sends back the object topi if this request is at the head of the queue.
• Whenpi receives the object, it uses the object, and eventually invokesrelease_ object(). This invocation entails sending a message RELEASE_OBJECT(i) to the home process p. Moreover, if the object has been updated bypi, theRE
-LEASE_OBJECT(i)message carries the last value of the object as modified bypi.
5.1 Mobile Object in a Process Graph 95
Fig. 5.1 Home-based three-way handshake mechanism
• When the home process receives a messageRELEASE_OBJECT(i), it stores the new value of the object (if any), and suppresses the request ofpi from its local queue. Then, if the queue is not empty,psends the object to the first process of the queue.
This three-way handshake algorithm is illustrated in Fig.5.1, with two processes pi andpj. When the home processpreceives the message REQUEST(j ), it adds it to its local queue, which already containsREQUEST(i). Hence, the home process will answer this request when it receives the messageRELEASE_OBJECT(i), which carries the last value of the object as modified bypi.
Discussion Let us first observe that the home processp can manage its internal queue on a FIFO basis or use another priority discipline. This actually depends on the application.
While they may work well in small systems, the main issue of home-based al-gorithms lies in their poor ability to cope with scalability and locality. If the object is heavily used, the home process can become a bottleneck. Moreover, always re-turning the object to its home process can be inefficient (this is because when a process releases the object, it could be sent to its next user without passing through its home).
5.1.4 The Algorithms Presented in This Chapter
The algorithms that are described in this chapter are not home-based and do not suffer the previous drawback. They all have the following noteworthy feature: If, when a processpi releases the object, no other process wants to acquire it, the object remains at its last userpi. It follows that, if the next user ispi again, it does not need to send messages to obtain the object. Consequently, no message is needed in this particular case.
The three algorithms that are presented implicitly consider that the home of the object is dynamically defined: the home of the mobile object is its last user. These
algorithms differ in the structure of the underlying network they assume. As we will see, their cost and their properties depend on this structure. They mainly differ in the way the mobile object and the request messages are routed in the network.