Concurrency and Distribution in Object-Oriented Programming

1. Concurrency and Distribution in Object-Oriented Programming Author : Jean-Pierre Briot Rachid Guerraoui Klaus-Peter Lohr Presented by Yiping Wang Date: 09/27/2010

2. Outline • 1. Introduction • 1.1 A Coarse Classification in Three Approaches • 1.2 Complementary of the Approaches • 1.3 Concurrency and Distribution • 2. The Library Approach • 2.1 Modularity and Structuring Needs • 2.2 Smalltalk Libraries • 2.3 C++ Libraries

3. Outline (cont'd) • 3. The Integrative Approach • 3.1 Unification Needs • 3.2 Dimensions of Integration • 3.3 Active Objects • 3.4 Synchronised Objects • 3.5 Distributed Objects • 3.6 Limitations of the Integrative Approach • 4. The Reflective Approach • 4.1 Combining Flexibility and Transparency • 4.2 Reflection • 4.3 Reflection and Objects • 4.4 Example of Meta-Object Protocols • 5. Summary

4. 1. Introduction • This paper aims at classifying and discussing the three approaches in object-based(OO) concurrent and distributed programming: Library, Integrative, and Reflective. • It discusses how object concepts are articulated ( applied, customized, integrated, expanded, and so on) with concurrency and distribution chanlleges.

5. 1.1 A Coarse Classification • Library Approach: It applies object-oriented concepts to structure concurrent and distributed systems through class libraries. • Integrative Approach: It consists in unifying concurrent and distributed system concepts with object-oriented ones. ( e.g., merging the notion of process and object into the notion of active objects ) not always smooth, may result in conflict. • Reflective Approach: It integrates protocol libraries within an OO programming language. Idea: separating the application program from various aspects of system implementation.

6. 1.2 Complementarity of the Approaches • Approaches first appear in conflict, while actually are not. • Library: It provides services and constructs for buiding the model through extended library. • Integrative: It aims at defining a high-level programming language with few unified concepts. • Reflective: Combines two approaches by making the separation of and interface between two levels. • Complementarity: Some languages and systems follow more than one approach.

7. 1.3 Concurrency and Distribution • Concurrency: Concurrency is a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. Different ways of running a concurrent program. The program may be executed on a uniprocessor, or on a parallel computer. • Distribution : Either sequenital or concurrent program may be executed across machine boundaries using remote calls. Distribution implies independent failure. the failure of one part of a program does not affect the rest.

8. 2. The Library Approach • 2.1 Modularity and Structuring Needs Idea: apply encapsulation and abstraction as a structuring tool to build concurrent and distributed system. Aims at building the system with a given OO methodology and programming language. The architecture of the system is organized by abstract notions of class components, which may come from the library offered. Two different example languages : (1) Smalltalk ; (2) C++

9. 2.2 Smalltalk Library • Smalltalk : considered as one of the purest object-oriented languages. Smalltalk itself is very simple. The richness of Smalltalk comes from its set of class libraries Even basic control structures such as loop and conditional, are just standard methods of standard classes . 2.2.1 Libraries for Concurrent Programming Standard Class: Process, ProcessorScheduler, Semaphore, Shared Queue, etc.

10. 2.2.1 Libraries for Concurrent Programming • Concurrency and mechanisms are well encapsulated and organized in a class hierachy. • They are much more understandable and extensible. • Furthermore, it is relatively easy to build up on the basic standard library of concurrency classes to construct more complicated abstractions.

11. 2.2.2 Libraries for Distributed Programming standard Smalltalk Binary Object Streaming Service (BOSS) library provides support for building distribution mechanisms. Proejcts like GARF go a step further in providing abstractions. In GARF, two complementary class hierarchies have been developed for various communication models.

12. 2.3 C++ Libraries • C++ is an object-oriented extension of C, a language originally designed for systems programming. • Since it has become the most widely used object-oriented language (in 1998), building libraries in C++ has been more than a marriage of convenience. • 2.3.1 Libraries for Concurrent Programming • Many concurrent programs are conveniently implemented using a threading system. We first look into threading libraries.

13. 2.3.1 Libraries for Concurrent Programming • In all thread approaches, creating a thread object spawns a new thread. An example is the coroutine part of Sun's C++ library. The library offers a class task, whose object is implemented as a coroutine with nonpreemptive scheduling.

14. 2.3.1 Libraries for Concurrent Programming(cont'd) • The ACE library : Adaptive Communications Environment One of the goals of the ACE is to present abstraction that subsume the threading mechanisms of different platforms (POSIX, Solaris, Win32), thus enhancing portability.

15. 2.3.1 Libraries for Concurrent Programming(cont'd) • ACE has classes Mutex, Semaphore, RW_Mutex, and others. A class template Guard is parameterized with a lock class. The Guard object acquires and releases a lock upon initialization and finalization, respectively. In ACE, Thread_Manager serves the purpose of creating and using thread. A high-level concept in ACE is the Task class. Task is an abstract class whose interface is designed for use according to the stream concept for layered communication.

16. 2.3.2 Libraries for Distributed Programming • We have seen that for C++, the library approach tends to mirror the functionality of the underlying system. This is true for distribution as well. • Choices is a generic operating system, of which the objective is to be able to adjust hardware, resources, and application interfaces • A specific C++ class library has been developed. Class Object-Proxy handles remote communication between objects, class MemoryObject represents memory management, and class ObjectStar provides generalized pointers. • The success of Choices projects helps in achieving better genericity and extensibility

17. 3. An Integrative Approach • 3.1 Unification Needs • In addition to classical sequental programming, concurrent programing introduces concepts such as process, thread, semphore, and transaction. • However, major issues still exist: programming with objects and managing concurrency and distribution of the program, also with objects but not the same objects. • Rather than leaving the object programs and the management of concurrency and distribution orthogonal, the integrative approach aims to merge them by integrating concepts and offering a unified model.

18. 3.2 Dimension of Integration • A first level of integration between the concept of an object and the concept of a process leads to the concept of an active object. • A second level of integration associates synchronization with object activation, leading to the notion of a synchronized object. • A third level of integration considers the object as the unit of distribution, leading to the notion of a distributed object.

19. 3.3 Active Objects • Basic idea: consider an object having its own computing resource, that is, its own private activity. • 3.3.1 Level of Object Concurrency: Serial or Atomic Quasiconcurrent Concurrent Fully concurrent • 3.3.2 Reactivity Versus Autonomy The integration of object with processes raises the issue of whether reactivity will be preserved or shadowed by the autonomous behavior of the process.

20. 3.3.3 Implicit Versus Explicit Acceptance • Implicit acceptance means that a message is automatically accepted after it is received. • Explicit acceptance means that the object explicitly states that it is willing to accept a certain pattern of message. • Most of the time, reactivity implies implicit acceptance, and autonomy always implies explicit acceptance. This is often the case, but not always. (ABCL/1, CEiffel) • 3.3.4 The Concept of a Body Some distinguished centralized operations that explicitly describe the types and sequence of requests the objet will accept during its activity.

21. 3.3.4 The concept of a Body • POOL example: • A POOL class for active Queue is shown below. A Queue object has a single thread of control. Its activity is described by the statement enclosed in the BODY/YDOB keywords (DO/OD is an infinite loop). • Notice that a missing body leads to DO ANSWER ANY DO, which models a reactive object .

22. 3.4 Synchronized Objects • Synchronization may be associated with objects and their communication means through various levels of identification. • 3.4.1 Synchronization at the Message Passing Level A straightforward transposition of the message-passing mechanism leads to implicit synchronization of the sender to the receiver (synchronous). In the case of active objects, it is useful to introduce asynchronous type of transmission by which the sender resumes without waiting for the completion of the invoked methods by receiver. Integration has the effect that strict synchronization is replaced with synchronization by need.

23. 3.4.2 Sychronization at the Object(s) level • Intraobject Synchronization When an object computing several requests simultaneously, It's necesarry to include some concurrency control in order to ensure the consistency. Example: Reader-Writer problem • Behavioral Synchronization It's possible that an object may temporarily be unable to access a certain kind of request. Typical example: Bounded buffer example • Interobject Synchronization Global synchronization : Money transfer between banks example.

24. 3.4.3 Synchronization Schemes • Centralized Schemes (path expressions) specify in an abstract and centralized way the synchronization of the object. • Decentralized Schemes (guards) specify at the program-area level the synchronization of the object. • Path expressions specify in a compact notation the possible interleaving of invocation. For example, a path expression like " {read}, write" might specify that either multiple simultaneous executions of read or a single execution of write but not both are allowed at any point in time.

25. 3.5 Distributed Objects • A natrual option for distribution is to consider an object as the unit of distribution and possible replication. • Furthermore, self-containedness of objects eases the issue of moving and migrating them around. • Also message passing provides the independence of its physical location. • Therefore, message passing may subsume both local and remote invocation as well as possible inaccessiblity of an object/service.

26. 3.6 Limitation of the Integrative Approach • The integrative approach attempts to unify object mechanisms with concurrency and distribution mechanisms. It leads, however, to some conflicts in the following. • Inheritance Anomaly (1) synchronization is difficult to specify and to reuse because of high interdependency. (2) various uses of inheritance may conflict each other. • Replication of Objects and Communications Unexpected duplication of invocations may lead in the best case to inefficiency and in the worst case to inconsistency.

27. 4 The Reflective Approach • 4.1 Combining Flexibility and Transparency It would be interesting to keep the unification and simplification of the integrative approach, while retaining the flexibility of the library approach. Different levels of concerns and use: integratived approach is for the application programmer and the library approach is for the system programmer. The task would be : how to combine these two levels of programming?

28. 4.2 Reflection • General methodology for describing, controling and adapting the behavior of a computational system. Basic idea: provide a representation of the important characteristics/parameters of the system in terms of the system itself. Reflection helps integrate protocol libraries intimatley within a programming language or system, thus providing the interfacing framework between the library and integrative approaches.

29. 4.3 Reflection and Objects • Reflection fits well with object concepts, thus it is natural to organize the control of behavior of system through a set of objects. This organization is named meta-object protocol (MOP) and its components are called meta-objects. • Reflection may also help in expressing and controlling resource management on a broad level such as processor, object group, scheduler, etc. Such resources are also represented by meta-objects.

30. 4.4 Example of Meta-Object Protocols (MOPs) • CodA is a representative model of a general MOP based on metacomponents. • CoDA considers seven metacomponents associated with each object. Attaching specific metacomponents allows selectively changing a specific aspect of the representation or execution model for a single project. A standard interface between metacomponents helps in composing metacomponents from different origins.

31. 5.1 Summary • In order to evaluate various object-based concurrent and distributed development, we have proposed three different yet complementary approaches in the community. • Library approach's limitation : the programming of the application and concurrent and distributed architecture, is represented by unrelated set of concepts and objects. • Integrative approach's limitation: the cost of the possibly reducing the flexibility and efficiency of the mechanisms. (e.g., inheritance anomaly nad duplication anomaly) • Reflective approach's limitation: It enforces the separation of their respective levels. It doesn't free us from the requirement of having good basic design of abstraction in concurrency and distribution system.

32. 5.1 Summary(cont'd) • Integrating the approaches Among the examples of languages and systems given in the article, some have been built following more than one approach. Common Object Request Broker Architecture (CORBA) is the example. CORBA integrates object and distrubition concepts through an object request broker. ( integrative approach) CORBA transaction service is specified in the forms of a class library of distributed protocol. ( library approach) CORBA supports customization of concurrency protocol and provides metacomponents facilities. In that sense, CORBA follows reflective approach.

33. Thank You!