PO(ID:6305/po:001)Concurrent OO LanguageConcurrent OO Language Related languages
References: Introduction The object paradigm has many pleasant properties such as uniformity, factorization and dynamicity. As opposed to the actor paradigm [1], the object paradigm is greatly lacking with regard to concurrency. The need to extend the semantics of objects to accommodate parallelism [10] has stimulated the proposals of several systems. In particular, investigation of the assumptions that connect objects with parallelism is fruitful. Two different solutions may lead to parallelism: i) objects are mostly passive and processes "execute through" them; ii) parallelism is closely tied to the concept of object. The first approach, adopted in Smalltalk-80, Loops and Flavors, imposes the presence of entities, the processes, that embody active execution threads. They are not 'normal' objects: therefore parallelism disrupts uniformity. Moreover, objects must be programmed taking into account the presence of processes. Parallelism obtained by following the second approach pays more attention to the 'objectness' of the system. This approach is employed by several systems such as EDEN [2], POOL/T (in [11]), ABCL/1 (in [11]), ConcurrentSmalltalk (in [11]), Orient84/K (in [11]), PO [3], MELD [5]. Objects, in addition to being the constructs to express information hiding and data abstraction, play the role of unit of concurrency. A combined solution may be advisable. An environment should mix both kinds of objects, passive and active, without imposing limits on reciprocal requests. This mixed solution is used by ConcurrentSmalltalk and PO. Extract: Granularity Of Parallelism Granularity Of Parallelism one has accepted the idea of tying objects to execution capacity, the granularity of parallelism is the In the following, we consider an entire range of possibilities. 1. Objects may be grouped into domains. Any domain hosts only one thread of execution at a time. Domains may enclose one or more objects [8]. Within a domain only one activity is in execution at a time. 2. Each object hosts only one thread of execution. Any object defines a single internal activity, the body (as is called in POOL/T), devoted to the service of one request at a time. The body is in charge of defining an internal scheduling to allow synchronization. An object may solve synchronization before starting the service of any request. This synchronization is a priori. In this case, an object does not activate an operation until all its preconditions are satisfied. The precursor language Simula67 [7], and its successors Beta [6] and [9], provide a set of coroutines for any object. The coroutines may derive from the combination of several class bodies, depending on inheritance. 3. Each object hosts more than one activity, but only one is in execution at a time. An object executes only one activity at a time, but several of them may have been started. Each activity is dedicated to the service of a request. In addition to case 1), those systems may define explicit internal synchronization tools such as semaphores or monitors. We call this a posteriori synchronization vs. the a priori one. The object internal activities are in charge of expressing their synchronization and they do it during their fifetime. Moreover, systems such as ABCL/1, ConcurrentSmailtalk, Orient84/K may predefine specialized scheduling strategies, such as priority, or express mode. 4. Several activities per object, any one for the service of an operation. All the current activities execute within the same object. So, several operations can be carried out in parallel. Synchronization can be either a posteriori as in EDEN or a priori or both as in PO. There are systems that constrain the maximum number of activities internal to an object (EDEN), others that do not (PO). 5. Several activities per object, both for the service of operations and to embody variables. An interesting decomposition encloses each internal variable within a dedicated activitv. This model solves synchronization automatically. Each reference to a variable implicitly provides synchronization. This decomposition scheme may be effective in highly parallel architecture. 6. Several activities per objects, one for any active statement. The granularity of an operation may be too coarse. All the statements, part of requested operations, become active and can execute in parallel. The system is in charge of deriving dependencies among statements and of running them in the most parallel fashion. MELD [5] exploits this approach achieving a declarative flavor. Parallelism, then. ranges from very limited patterns to very granular solutions. But, as the same time, the expressive capacity offered to a user cannot be too complex. Approaches 1), 2) and 3) impose limits on the expressive power of objects. There may be cases where a specific synchronization may be cumbersome to solve. In 5), without any priority to distinguish activities, once an operation has started,the object cannot pay any attention to other events. Moreover, the models proposed in accord with 1) and 2) are reluctant to accept any multiplexing in order not to lose the automatic mutual exclusion on object operations. Solutions 5) and 6) represent approaches suited to automatic tools that identify implicit parallelism. The user must not worry about such a decomposition. These models are more suitable for the system level. Moreover, excessive granularity of parallelism can rapidly produce saturation because of the synchronization load. It is still questionable whether such solutions can produce performance improvements, especially on traditional machines with a low degree of parallelism. At the same time, too fine a grain of parallelism may be unusable for many applications. Approach 3) can be a good compromise that gives the programmer the chance of expressing the maximum parallelism he/she wants. In the next Section, we present briefly PO, a parallel object model that follows the third approach. Extract: The PO Model The PO Model In the following, we examine the Parallel Objects proposal (PO for short), focusing on the aspects related to concurrency. In PO, an object can be an active object (Aobject for short). An Aobject is alone responsible for its own integrity. External activities cannot access private information of an Aobject. Each Aobject decides not only how to respond to any external request, but also when to execute an operation. In PO, two forms of parallelism are possible: i) interobject parallelism; ii) intraobject concurrency. The first component is derived both from the association of execution capacity to any Aobject and from the asynchronous interaction between Aobjects. In fact, an Aobject is independently capable of execution, i.e. it executes on its own. When an Aobject requests another object for an operation, it is forced to wait for the result only if it uses a synchronous mode of communication. In PO, two kinds of asynchronous communications are possible: the "pure" asynchonous mode that neglects the answer and the asynchronous mode with possibility of receiving the reply in the future. The last kind is called future asynchronous mode in ABCL/1. The second form of parallelism, the intraobject one, arises from the existence of multiple activities in the same Aobject. In the following, we stress this aspect. 3.1 Intraobject Concurrency A number of activities can be present within the same PO Aobject. For classification's sake, we examine in the following several properties related to P© h~terna] activities. - association request/activity. Any request of operation served by an Aobject generates a new activity dedicated to it. This activity executes the operation and is destroyed at the operation end. - number of hosted activities. An Aobject of PO can host an illimited number of activities. By default, the system is in charge of furnishing an intraobject scheduling policy. In this case, the programmer simply specifies object operations. - Synchronization of internal activies. Different activities internal to the same Aobject may need synchronization. We distinguish two kinds of synchronization on the basis of when the internal synchronization is specified. In fact, PO makes possible to use a posteriori and a priori schemes or both. In the a posteriori case, the activities are responsible for synchronizing with each other, after their creation. Instead, in the a priori case, an Aobject does not generate an activity as long as it potentially conflicts with any existing one. For this reason, in each PO Aobject, there is a particular activity, the scheduler, that is in charge of monitoring activities by using a specified policy. This scheduling policy may be explicitly specified by the programmer or even inherited. In fact, PO introduces three different levels to define scheduling policy depending on the programmer's skill [4]. The first, highest level furnishes the programmer with an implicit policy that the PO system gives by default. For example, it may be a policy that sequentializes any Aobject (as in the approach 2) described in Section 1). The third, lowest level gives the programmer the chance of specifying in a uniform way its policy. The programmer writes dedicated methods (scheduling methods) to express the scheduling strategy for a class of Aobjects. In this way, PO takes advantage of inheritance of the concurrent specifications. So, the code of the scheduler is composed of the combination of all the visible scheduling methods found in the inheritance graph. The second, intermediate level allows the programmer to define its scheduling policy by using pre-defined constraints. The inheritance also holds for constraints. All the constraints are composed in a set of constraints for an Aobject class, that is then automatically translated into scheduling methods. Conclusion And Directions For Further Investigation Concurrency is actually one of the neglected issues of object systems. The majority of them simply introduce processes as instances of a system class. This dichotomy, passive objects/active processes, contrasts with object uniformity. The integration of execution capacity with the object paradigm is an issue only partially faced, even if precursor systems, such as Simula67, introduced it since some twenty years ago. PO is an example of insertion of parallelism in an object framework that follows the principle of uniformity. In particular, PO takes advantage of classification and multiple inheritance in the specification of internal scheduling policy. As open directions, parallelism has impact on many other non-solved issues: i) object can furnish a framework for load sharing and even hardware fault tolerance; ii) concurrency within objects can be a crucial point for the definition of object migration. In the future, we intend to accomodate these issues within the PO model. in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details in SIGPLAN Notices 24(04) April 1989 incoroporating Proceedings of the 1988 ACM SIGPLAN workshop on Object-based concurrent programming, San Diego view details in Concurrency: Practice and Experience 2000 v12 view details |