Using Logical Operators as an Extended ... - Semantic Scholar

Proc. of the 2002 Coordination Conference, York, England, April 2002, pp 315–331

Using Logical Operators as an Extended Coordination Mechanism in Linda Jim Snyder and Ronaldo Menezes? Florida Institute of Technology Department of Computer Sciences Melbourne, Florida, USA [email protected],[email protected]

Abstract. In the last 20 years of research in coordination, researchers were able to demonstrate that distributed languages are made of two distinct parts: a computation and a coordination language. Among a plethora of coordination models (the basis of a coordination language) available today, Linda is perhaps the most successful. Linda advocates that processes should interact solely via associative shared memories called tuple spaces. Linda has developed from a single-tuple-space into a multiple-tuple-space model but the coordination mechanism used was never extended to express the multiple-tuple-space model full potential. This paper describes an extension of the Linda model, called LogOp, where primitives can use logical operators to combine tuple spaces onthe-fly. It is argued that LogOp provides a simpler and more elegant coordination mechanism than Linda. An implementation of LogOp is also described and initial results indicate that LogOp implementations are efficient when dealing with multiple tuple spaces.

1

Introduction

Coordination is a fast-growing research area. Emerging fields such as mobile computation and mobile computing, amorphous computing [1], and large scale Internet applications require non-trivial coordination patterns. Linda [3] is arguably the most important coordination model. Linda has suffered a series of extensions. Among these, the extension from a single tuple space to a multiple tuple space model [4] can be said to be of prime importance for it made the model a better abstraction for open distributed systems. Despite all research in Linda, little has been done to improve the suitability of the model to areas of computer science that require advanced coordination patterns. There are a few good specialized extensions of Linda for a variety of fields but none has looked into exploring the full potential of features already provided in Linda such as multiple tuple spaces. This paper argues that the ?

Corresponding author

2

J. Snyder and R. Menezes

potential of the multiple-tuple-spaces abstraction is yet to be explored because the Linda primitives provide a very basic coordination mechanism when it comes to using multiple tuple spaces. This paper introduces LogOp, a Linda-based model that uses logical operators at the primitive level to provide an extended coordination mechanism, which is better suited to the multiple tuple space abstraction. This paper is divided as follows: Section 2 describes the Linda model; Section 3 describes LogOp model and the semantics of its primitives when used with logical operators; Section 4 describes a LogOp implementation; Section 5 describes some preliminary results that demonstrate that the expressiveness of LogOp has some influence on the performance of the implementation; Section 6 identifies other works that are related to the expressiveness of Linda; and Section 7 discusses future work and present the conclusion.

2

Background

Linda provides primitives to processes enabling them to store and retrieve tuples from tuple spaces. Although the names of the primitives vary slightly in different implementations, the functionalities are normally very similar. Processes use the primitive out to store tuples. They retrieve tuples using the primitives in and rd. These primitives take a template (a definition of a tuple) and use associative matching to retrieve the desired tuple — while in removes a matching tuple, rd takes a copy of the tuple. Both in and rd are blocking primitives, that is, if a matching tuple is not found in the tuple space, the process executing the primitive blocks until a matching tuple can be retrieved. The blocking nature of these primitives and the fact that they can only deal with one tuple space at a time motivated the proposal of LogOp In addition to the primitives above some Linda implementations provide non-blocking versions of in and rd, called inp and rdp respectively. These primitives have the same semantics of their blocking counterparts when a matching tuple is can be found in the tuple space. However, they behave significantly different if a matching tuple cannot be found — they fail instead of blocking. The standard Linda assumes a single tuple space. In the multiple tuplespaces variants, these spaces are disjoint. In other words, processes can only access one tuple space at a time — processes that require access to several tuple spaces have to do so by serializing the access. Although this serialization is reasonable in many cases, it limits the ability of Linda to express coordination where the contents of different tuple spaces need to be considered as a whole. For instance, in producer-consumer architectures the type of coordination described in Figure 1 appears frequently. In the scenario depicted in Figure 1 a process X is waiting for a tuple to appear in either of the tuple spaces so it can proceed. This situation is also commonplace in other areas such as job scheduling. In job scheduling Figure 1 could be used to represent a process X that depends on the termination of either process A or B. Despite the simplicity of this scenario, Linda is unable to properly express it if ordering is not important.

LogOp Linda

3

Fig. 1. Process X wants access to both tuple spaces but does not want to impose any ordering in the access.

Due to its blocking nature, in cannot be used to implement the scenario. This paper proposes to extend the primitives so that they can deal with more than one tuple space at a time, thus allowing simple scenarios such as the one depicted in Figure 1 to be elegantly expressed.

3

LogOp Linda

LogOp is a coordination model which aims at improving the expressiveness and efficiency of Linda primitives. Linda is widely acceptable in the coordination community due to its elegance and simplicity but it lacks the ability to maintain its elegance in problems such as the one described in Section 2. Efficiency is also a concern for LogOp. Some could argue that models are not directly linked to efficiency. However, a good, well-thought, model is likely to produce better implementations — the model’s characteristics are embedded into their implementations. Very few models have looked into improving the efficiency of their implementations by modifying the model characteristics. Rowstron’s work on efficiency of open Linda systems has produced two interesting models whose implementation were shown to be more efficient than implementations of the standard Linda model. Rowstron’s models assume that tuple spaces are organized in a hierarchy[12], and add the concept of asynchronous primitives [13]. LogOp primary concern is expressiveness but it tries to achieve good performance at the implementation level as a consequence of expressiveness. This

4

J. Snyder and R. Menezes

approach is different from Rowstron’s approaches where performance is the main focus — implementations should be efficient even if expressiveness is lost. Section 2 described a simple situation where two independent processes are producing data to a consumer using different tuple spaces. While in some cases it may be possible to use a single tuple space to store the produced data, this assumption, besides restrictive, is not always true. It is not uncommon for processes to maintain their data separately while another process is dependent upon the generated data. while (true) t := in(tsA, [?int]); doW ork(t); t := in(tsB, [?int]); doW ork(t); end Fig. 2. Pseudo-code demonstrating that in is not suitable to implement process X in Figure 1.

Figure 2 shows process X (consumer in Figure 1) using the primitive in. It is clear that this example does not express the consumer process X correctly; the process will block on tuple space tsA first and then on tsB. This solution is incorrect because the data produced in tsB would never be consumed unless data is also produced in tsA. In fact, the number of elements produced in both tuple spaces must always be the same. Thus, in is not the appropriate primitive to be used in this case. while (true) t := inp(tsA, [?int]); if (!isEmpty(t)) doW ork(t); end t := inp(tsB, [?int]); if (!isEmpty(t)) doW ork(t); end end Fig. 3. Possible solution using inp.

One may be tempted to solve the problem using inp instead of in since inp is not a blocking primitive. Figure 3 shows such a solution. Although this solution will correctly produce the desired results, it is also extremely inefficient. The

LogOp Linda

5

polling caused by the execution of the process may make it prohibitive. At each loop iteration the process will make up to N requests where N is the number of tuple spaces involved in the operation. It is not difficult to see that if several process constantly rely on this solution to get data from tuple spaces, the Linda kernel may quickly become a bottleneck given the number of requests it has to process. LogOp was developed to tackle problems as the one described above. It is easy to observe that the required associations amongst the tuple spaces relate to basic logical operators such as and, or and not. These operators are used in LogOp primitives making them more suited to deal with multiple tuple spaces.

< PRIMITIVE > (< EXP >, < TUPLE >) where ::= () ::= | , ::= handle | ::= and | or | not ::= in | rd | out := tuple | template Fig. 4. BNF of LogOp primitives.

The BNF in Figure 4 describes the general form of LogOp primitives. LogOp adds the feature of combining tuple spaces with logical operators. The logical operators may be used in conjunction with most primitives. However, this paper describes the semantics only for the standard blocking and non-blocking primitives (in, rd and out). The BNF is meant to show what type of expression can be used in the LogOp model. For instance the grammar recognizes an expression such as in (or (ts1,ts2,ts3),[?int]). Another issue that had to be addressed was the subset of logical operators being considered. As shown in Figure 4 this paper describes only the operators and, or and not. The choice for working with these operators does not make LogOp any less general. It is known that logical expressions involving other operators can be reduced to an equivalent one using and, or and not. Yet, the explicit use of other logical operators improves expressiveness and will be considered in future work. In the sections to follow, the semantics of each logical operator is described in the context of all three primitives. 3.1

The or Operator

The or operator has the effect of combining tuple spaces so that processes can store and retrieve tuples from any of the tuple spaces from a list without having

6

J. Snyder and R. Menezes

to impose an order on the way the tuple spaces are accessed. For instance, consider once again the scenario in Figure 1. It may be necessary for a process (say a consumer) to read tuples from any of several tuple spaces. The or operator, when used to combine tuple spaces, allows processes to express this scenario. When storing tuples the use of the or operator adds another level of non-determinism to the model. The informal semantics of each of LogOp primitive is as follows: out : The use of an out along side with the or operator causes a tuple to be placed in any of the tuple spaces defined in the primitive. The tuple space is chosen non-deterministically. For instance, out (or (ts1,ts2),[‘‘Hello’’]) will store the tuple [‘‘Hello’’] in either ts1 or ts2. The choice of which one is made non-deterministically. The semantics of a conditional or was used here. Due to the fact that an out operation always succeeds, the use of an logical or would make the it similar to the out using the and operator. in, rd : The use of an in and rd along side with the or operator will make LogOp search for a tuple matching the given template in the tuple spaces defined in the operation. If none of the tuple spaces contain a matching tuple the process blocks until a tuple is placed in any of the tuple spaces and can be retrieved. For the primitive to succeed (not block) a tuple must be found in one or more of tuple spaces in the list. These primitives return a list of tuples found. If the or operator takes n tuple spaces, the result is a list containing at most n tuples and at least 1 (one) — since 0 (zero) makes the process block. For instance, when a process executes in (or (ts1,ts2,ts3),[?string]) it blocks if tuples matching the template [?string] cannot be found in any of the tuple spaces listed. If a matching tuple can be found in one of these tuple spaces the process will not block and the tuple is returned. One other case is when a matching tuple is found in more than one tuple space. In this case a list of tuples will be returned. This list contains one tuple from each tuple space where a matching tuple could be found. The semantics tries to follow the exact definition of a logical or (as opposed to the concept of a conditional or). At the implementation level it may be possible to implement both variants so as to maximize parallelism or/and improve efficiency. It is clear that this definition is not symmetric to the given definition of the or when used with an out. inp, rdp : These primitives are failing versions of the primitives above. inp and rdp behave exactly like the primitives above when a matching tuple can be found in at least one tuple space. The difference in this case is when a matching tuple cannot be found in any of the tuple spaces. While the primitives in and rd block, inp and rdp would fail returning an empty list of tuples to the process. Figure 5 shows the solution for the producer consumer problem described earlier. Observe that LogOp is able to express the solution in a very elegant way. This simple example already shows a case where LogOp expressiveness has an impact in the solution.

LogOp Linda

7

while (true) t := in(or(tsA, tsB), [?int]); doW ork(t); end Fig. 5. Process in LogOp representing a consumer in the scenario depicted in Figure 1.

The idea that primitives may return a list of tuples instead of a single tuple is also a consequence of the extension of the primitives to the multiple tuple space model. The decision to make the getter primitives (in, inp, rd, rdp) return a list of tuple spaces is based on the logic behind the operator or. If one assumes that there is a true or false value associated with a tuple space (depending on whether the tuple space contains a matching tuple), one could use boolean logic to find out the action that results from the execution of a getter primitive. Since several false values combined with or result in false, the primitive fails — in the case of in and rd this causes the process to block. On the other hand, if at least one tuple space has the value true the result of the or operator will also be true meaning that primitive succeeded in getting a tuple (or more). Table 1 summarizes the action in all cases involving two tuple spaces. Note that true means that a tuple space has a matching tuple and false means that a matching tuple cannot be found. ts1 false true false true

ts2 Action false Fail false One tuple is returned true One tuple is returned true Two tuples are returned

Table 1. Summary of the action upon the execution of getter primitives along with or.

3.2

The and operator

The and operator allows processes to consider all tuple spaces in a list. The use of and to combine tuple spaces ranges from event notification to broadcast of information. The semantics of this operator is not as obvious as the semantics of or and need a more detailed description: out : The use of and with an out allows processes to store a tuple in a list of tuple spaces in just one step. Although broadcast operations are not easily expressed in Linda, the LogOp version of this primitive is more elegant and is likely to generate a more efficient implementation — if n tuple spaces are involved in the operation, Linda would have to execute the out primitive n

8

J. Snyder and R. Menezes

times. This operation could be very expensive due to the overhead associated with sending n messages separately to the kernel. In LogOp only one message is sent to the kernel. Once the message is in the kernel, it is stored in the individual tuple spaces. in, rd : The and operator can also be used in blocking primitives. The semantics of these primitives is such that the process will block if one ore more tuple spaces in the list fail to contain a tuple matching the template given in the primitive. Similar to the or case, the decision on whether the primitive fails (block) is made based on the concept that tuple spaces have the true or false values associated with them. For an and to produce true all tuple spaces that are considered in the primitive must have value true — they all must have a matching tuple. The primitive returns a list containing n tuples — one from each tuple space, where n is the number of tuple spaces considered in the operation. inp, rdp : These primitives are failing versions of the ones above; thus they never block. When used with an and to combine tuple spaces, these primitives either return a list containing n tuples, where n is the number of tuple spaces defined in the primitive, or return an empty list. It should be noticed that a naive implementation of the operator and with getter primitives may cause deadlock. Suppose a process executes an in combining two tuple spaces, ts1 and ts2, using an and. If the implementation is such that a matching tuple is retrieved from tuple space ts1 before knowing whether tuple space ts2 also has matching tuple, a deadlock may happen if these operations are performed while another process grabs a matching tuple from ts2 and blocks on ts1. This situation is not uncommon but it is not a problem introduced by LogOp. In fact, LogOp may actually be a better solution than using the original primitives in series when it comes to avoiding deadlocks of this kind. Using standard primitives the programmers would have to control these situations. In LogOp, in some cases, the kernel may be able to identify a possible deadlock situation and use a deadlock avoidance mechanism to deal with the problem. LogOp kernel should implement the blocking primitives as atomic operations. This may be achieved using transactions — a process either get all tuples it requires or none. The control of the blocked process by the kernel has to be done with care. The kernel may maintain a list of blocked process and keep track of tuples being stored or retrieved using a tuple-monitoring sub-system [8] so as to be able to unblock process whenever possible. 3.3

The not operator

Before describing this operator, it is important to explain the concept of a complement of a tuple space that is used in the semantics of the not operator in LogOp. In any implementation of Linda it is possible for the kernel to keep track of the tuple spaces that a particular process knows. This idea has been

LogOp Linda

9

implemented already in a few Linda systems [11, 7]. In LogOp the complement of a tuple space tsA (or not (tsA)), represents the set of all tuple spaces that a process has knowledge of beside tsA. Note that the complement of a tuple space may differ from process to process. This is the case because the universe set used to compute the complement depends on the process executing the operation. The complement is not based on the total number of tuple spaces available in the system because this would generate security concerns such as a process accessing a tuple space private to another process. Additionally, since the universe set used is independent for each process, the creation of a tuple space by another process does not side effect the execution of not. There is an equivalence between the not operator and the or operator. The execution of a primitive using a not (tsA) by process P1 is the same as the execution of the same primitive along with an or in the complement of tsA from the point of view of P1. However, LogOp includes this operator to improve the expressiveness of the system — instead of writing a long list of tuple spaces combined by or except for one, the programmer could just use the not. The specific semantics of not when used in conjunction to the each of the primitives are: out : The semantics of not with out is quite straightforward. The tuple will be non-deterministically stored in any of the tuple spaces that form the complement of the tuple spaces defined in the operator. Since it has been shown that there is a relationship between not and or the semantics here is similar to the semantics for the operator or. in, rd : Here also the semantics is equivalent to the use of or in the complement of the tuple spaces defined in the not operator. The process will block if a matching tuple cannot be found in any of the tuple spaces that form the complement of the tuple spaces. This primitive returns n tuples where n is the number of tuple spaces that contain a matching tuple. inp, rdp : These primitives are failing versions of the primitives above. If a tuple cannot be found in any of the tuple spaces forming the complement of the tuple spaces defined in the operation the primitive fails and returns an empty list. Figure 6 shows a process in LogOp making use of the not operator. If one assumes that this process currently knows about three tuple spaces: ts1, ts2 and ts3, the execution of the primitive in Figure 6 is the same as executing out (or (ts2,ts3),[45,‘‘Hello’’]).

out(not(ts1), [45,00 Hello00 ]); Fig. 6. Using the not operator applied to tuple space ts1.

10

J. Snyder and R. Menezes

It should be noticed that deadlock may also occur if the not operator is used incorrectly. Suppose for instance that a process only knows about one tuple space, say ts1. If a process contains the execution of an in or a rd on not (ts1) the process will go into a deadlock situation. Because the process is blocked, it cannot acquire knowledge of other tuple spaces. Consequently, not (ts1) will always be an empty list. In these situations it may be desirable to have the LogOp kernel reject the primitive. Since the kernel can find out that the complement of a tuple space is an empty list, it could generate some exception or make the primitive fail. Either solution will affect the known semantics of the blocking primitives as failing is not part of the expected behavior of an in or a rd.

4

Implementation

A LogOp prototype has been implemented using Java. LogOp uses an open client-server architecture where the number of servers and clients is not predetermined at compile time. In order to avoid bottlenecks, multi-threading is extensively used. Each LogOp server has four threads: two dealing with server requests and two dealing with client requests. A pair of threads is used to connect servers and clients in order to make the task of receiving objects and sending objects concurrent. On the client side, each LogOp primitive has its own thread as this improves performance when large quantities of primitives need to be processed. A list of LogOp servers available in the system is statically kept in file. This file is loaded by the servers when they start. New servers can start at any time and if they were not originally listed in the file they add their names to the file and broadcast to other servers the information that they are now available in the system. Currently, the client tries to connect to a server in the same machine (same IP address) and if one is not available a server is chosen randomly from the list of servers available in the system. After the connection is established, the server chosen becomes the default server for this client. LogOp uses the concept of distributed central servers, where the tuple spaces contents are not distributed across several servers — each tuple space is entirely stored in one server. When a server receives a request to create a tuple space, it creates the tuple space locally. One of the properties of a tuple space is its location (IP number of the server where the tuple space is stored). This property is used to route requests that processes make to different tuple spaces. When a client executes a getter primitive, the request is sent to the process default server. In the LogOp server, the operation is broken into smaller operations by a server component named the decomposer and the list of tuple space analyzed. The decomposer takes the list of tuple spaces and groups them by IP addresses. After they are grouped each server involved in the primitive is contacted. The server receives its list of tuple spaces, the primitive being executed, and the logical operator used to combine the tuple spaces. Then, the default server waits for an answer from all the other servers involved. As responses come

LogOp Linda

11

back from other servers, their tuples (if any) are placed into a list object that will be returned to the client process. When all responses are received, the object is sent back to the client. When a client executes a setter primitive such as an out, the request is sent directly to the client’s default server. Again the decomposer analyzes the list of tuple spaces and groups them based on their IP addresses. The tuple is then sent to each server involved in the operation so that they, in turn, can store the tuple in the tuple spaces. This process is slightly different when or is the operator being used since the default server chooses one of the tuple spaces in the list to send the tuple. After the default server acknowledge that the message was received, the client is allowed to proceed (the primitive returns). It should be noted that the above does not mean to say the an out is a blocking primitive. The need for an acknowledgment is mainly due to the outordering requirement [2]. 4.1

Using Wrapper Functions

It is important to discuss the issue of using wrapper functions to implement the LogOp logical operators. The name wrapper functions refers to the fact that they combine existing functions into a new function that achieves the desired functionality. In the case of LogOp it is true to say that wrapper functions could be used to provide the same expressiveness as LogOp operators. However, LogOp is a coordination model and should not rely on artifacts of computation languages to achieve advanced coordination mechanisms. Additionally, wrapper functions are normally implemented just as a mere translation from one function call to the (several) original function calls. In other words, the expressiveness of a possible solution using wrapper functions would be achieved using the standard primitives. Therefore all the problems already described, such as polling, would still be present in the system.

5

Preliminary Results

This section covers some preliminary results on the performance of LogOp’s primitive in. Three machines on the same subnet running Sun’s Solaris 8 were involved for testing purposes. The first system (machine X) contains four CPUs and 1Gb of memory. The other two systems (machines A and B) are Sparc 5 with 256Mb of memory. The goal of the experiment is to demonstrate the advantages (in terms of execution time) of LogOp’s primitives when compared to Linda’s. Four tuple spaces were created in the systems: two tuple spaces, ts1 and ts2, held in machine A and the other two, ts3 and ts4, held in machine B. Three processes were implemented. Two of them (in machine A and B) created the tuple spaces and stored a number of tuples in each tuple spaces. The third process was placed on machine X and had the job of retrieving all the

12

J. Snyder and R. Menezes

tuples stored in all four tuple spaces. The test sample consists of six different counts of tuples: 100, 500, 1000, 5000, 10000 and 15000. The number of tuples were divided equally amongst all four tuple spaces. In LogOp, due to the existence of the and operator, the producer processes (in machine A and B) store the tuples using the code shown in Figure 7. In fact, the producer processes differ slightly since they deal with different tuple spaces. Figure 7 shows the code for producer in machine A. The code for the consumer process has to consider all four tuple spaces at the same time. This is shown in Figure 8 where the consumer also make use of the and operator. The traditional way to implement this idea in Linda is by serializing the primitives which diminishes the degree of parallelism of the implementation. The code for the standard Linda does not use the and operator. Therefore, the producers will have two primitives out, one after the other, whereas the consumer will have four primitives in. while (index < maxT uples) do out(and(ts1, ts2), new Integer(index)); index + +; end Fig. 7. Code for producer process in LogOp.

while (index < maxT uples) do in(and(ts1, ts2, ts3, ts4), new F ormal(“Integer”)); index + +; end Fig. 8. Code for the consumer process in LogOp.

Table 2 shows a comparison of the times taken to retrieve all the tuples in all tuple spaces using Linda and using LogOp. This table does not account for the cost of the out primitive, only the time taken to perform the in primitives is measured. It can be seen in Table 2 that in average Linda took approximately 50% more time than LogOp to perform the operations. In a similar experiment with the primitive out, it was also found that LogOp performed a little better. However, the gain is not too significant due to the fact the out is normally an efficient primitive. When compared against a series of inp primitives, instead of in, the results were similar to the results described in Table 2. This outcome was expected since

LogOp Linda

13

No. Tuples Time in Linda Time in LogOp 100 21.634 11.522 500 106.072 55.796 1000 210.882 113.380 5000 1043.950 554.677 10000 2083.667 1111.477 15000 3185.943 1666.896 Table 2. Comparison of Linda and LogOp of the time taken to retrieve tuples based using in.

the tuples were placed in the tuple spaces before the execution of the consumer and the semantics of inp and in are the same when a matching tuple is found.

6

Related Work

Merrick and Wood [9] have proposed to replace the idea of tuple spaces with the concept of Scopes. In their model tuples can belong to multiple scopes. Scopes are created either empty (no tuples) or by combining other existing scopes. In terms of expressiveness, Scopes is better than Linda and it can indeed model more coordination patterns than Linda. However, in order to solve problems as the one depicted in Figure 1, a new scope will have to be created combining the two existing ones. While this assumption is not a problem in small systems, the creation of these scopes in large dynamic systems may force many extra structures to be created. Furthermore, a scope is a “permanent” structure that need to be explicitly created. In LogOp the model (Linda) is not changed nor any extra structure needs to be created — tuple spaces are combined on-the-fly and only from the point of view of the process executing the primitive. Another solution that aims at modeling the examples described in this paper are the event-driven coordination models such as Lime [10] and TSpaces [5]. In these models, processes can register for events in the kernel. Once processes are registered, the kernel notifies them every time the event takes place. For instance, a process could register with two tuple spaces to receive any tuples that match the template [?int]. From the moment processes register onwards, if a tuple arrives in any of the two tuple spaces and this tuple matches the given template, the tuple is immediately sent to the process. Event-driven coordination models are very powerful and are able to express diverse coordination patterns. Yet, these models are aimed at avoiding blocking of processes. Processes normally register for an event but carry on with their execution. Event-driven models are analogous to the idea of subscribing to a mailing list for instance; once you say you want to receive messages, the messages will keep arriving in your mailbox until you cancel your subscription (cancel the event).

14

J. Snyder and R. Menezes

Jacquet and De Bosschere describe an extension of the µLog model where relations between blackboards can be defined [6]. However, the relations are normally defined as rules of pertinence of tuples in the blackboards. For instance, they are able to express with these rules that if a tuple t is placed in blackboard A it should also be placed in blackboard B. Surely this is somewhat similar to an and; the difference in LogOp is that rules are not created per se and no relation between tuple spaces is created in the context of the entire system. LogOp offers more flexibility as it allows users to define the scope of the primitive on-the-fly. LogOp primary concern is with blocking primitives. It extends the model to allow a process to wait on several tuple spaces at the same time, without imposing any ordering. Another difference between LogOp and event-driven models is that events (normally tuples) are sent one at a time from the kernel to the process, while LogOp allows for several tuples to be retrieved at the same time. For instance the use of and forces the kernel to return either N tuples or none. In a event-driven model this would be difficult to achieve since tuples would be sent to the process as they appear in the tuple space.

7

Conclusion and Future Work

This paper described an extension for the Linda model that makes better use of multiple tuple spaces. It has been argued that the extensions provided in LogOp allow for more elaborate synchronization architectures when compared to the standard primitives of Linda. It has been demonstrated that for a class of problems where simultaneous access to several tuple spaces is required, Linda is not able to express a reasonable solution. LogOp allows the programmer to combine tuple spaces using the abstraction provided by logical operators. It is believed that such abstraction is quite natural when dealing with tuple spaces. A LogOp prototype has been implemented and the experiments look promising. This confirms the expectation that changes in the model level would affect the performance of implementations. Future work in LogOp involves implementing a fully functional system where logical operators besides and, or and not are not available. It is also desirable to have a module in the kernel that can apply simplification rules to the expressions involving tuple spaces. This on itself is a difficult task but should allow the implementation to work with more elaborate expressions. Further work is still required on the semantics of LogOp primitives. It is unclear what should be the behavior of the processes when faced with more elaborate expressions such as in (or (ts1,not (ts2),and (ts1,ts3)),[?int]). Again, the implementation of a logical expression evaluator should shed some light on the semantics on LogOp. Finally, it would be interesting to see how logical operators could be applied to templates. This would create a LogOp implementation with two levels of logical operators. In this system, one would be able to express: retrieve a tuple matching either template A or template B which is stored in either tuple space

LogOp Linda

15

X or tuple space Z. This extension is being planned to be added to LogOp after the implementation of a more elaborate logical expression evaluator.

References 1. H. Abelson, D. Allen, D. Coore, C. Hanson, G. Homsy, T. F. Knight, R. Nagpal, E. Rauch, G. J. Sussman, and R. Weiss. Amorphous computing. Communications of the ACM, 43(5):74–82, May 2000. 2. A. Douglas, A. Wood, and A. Rowstron. Linda Implementation Revisited. In P. Nixon, editor, Proc. of the 18th World Occam and Transputer User Group, pages 125–138. IOS Press, April 1995. 3. D. Gelernter. Generative Communication in Linda. ACM transactions in programming languages and systems, 1:80–112, 1985. 4. D. Gelernter. Multiple Tuple Spaces in Linda. In Proc. of PARLE 89, pages 20–27. Springer-Verlag, 1989. 5. IBM Corporation. T Spaces Programmer’s Guide, 1998. Eletronic version only. http://www.almaden.ibm.com/cs/TSpaces/. 6. J. Jacquet and K. DeBosschere. On Relating Blackboards in the mLog Coordination Model. In Proc. HICSS30, Sw Track, pages 359–368, Hawaii, 1997. IEEE Computer Society Press. 7. R. Menezes. Experience with Memory Management in Open Linda Systems. In Proceedings of the 16th ACM Symposium on Applied Computing, pages 187–196. ACM, March 2001. 8. R. Menezes and A. Wood. Garbage Collection in Linda using Tuple Monitoring and Process Registration. In Proc. of the 10th International Conference on Parallel and Distributed Computing and Systems, pages 490–495, Las Vegas, Nevada, USA, 1998. Acta Press. 9. I. Merrick and A. Wood. Coordination with scopes. In Proceedings of the 2000 ACM symposium on Applied computing 2000, volume 1, pages 210–217, Como, Italy, March 2000. ACM. 10. G. P. Picco, A. L. Murphy, and G.-C. Roman. Lime: Linda Meets Mobility. In D. Garlan, editor, Proceedings of the 21st International Conference on Software Engineering (ICSE’99), pages 368–377, Los Angeles, CA, USA, May 1999. ACM Press. 11. A. Rowstron. WCL: A co-ordination Language for geographically distributed agents. World Wide Web, 1:167–179, 1998. 12. A. Rowstron and A. Wood. An Efficient Distributed Tuple Space Implementation for Networks of Workstations. In L. Boug´e, P. Fraigniaud, A. Mignotte, and Y. Robert, editors, Euro-Par’96, volume 1123 of Lecture Notes in Computer Science, pages 510–513. Springer-Verlag, 1996. 13. A. Rowstron and A. Wood. Bonita: A Set of Tuple Space Primitives for Distributed Coordination. In H. El-Rewini and Y. N. Patt, editors, Proc. of the 30th Hawaii International Conference on System Sciences, volume 1, pages 379–388. IEEE Computer Society Press, January 1997.