Concurrent Object-Oriented Programming Languages

1. Concurrent Object-Oriented Programming Languages Chris Tomlinson Mark Scheevel

2. Introduction (i) • Concurrency • multiple independent activities within a system, including control and communication • Message passing • distinguish between • metaphor for interaction among objects • ”real” message passing as communication in the context of concurrent computational activity • A number of design issues for the latter can be safely ignored when there is no real concurrency

3. Introduction (ii) • In the message passing metaphor objects are autonomous active entities that synchronize and exchange information by sending messages • This has advantage over shared memory approaches that separate the universe into passive data and active processes • Message passing combines information transfer with synchronization into one construct (more favourable than the use of semaphores) • A shared memory model does not lend itself very well to distributed implementations

4. Introduction (iii) • Reasons to consider explicit features of concurrency in programming languages • The world is concurrent and the task of program design will be eased if expressing concurrency is closely matched to the concurrency to be modelled • Performance gain over sequential implementations • Replication of processing can benefit from a well designed method of expressing concurrency

5. Introduction (iv) • Benefit of object orientation • object orientation describes things as multiple independent and interacting entities • high degree of reference locality minimizing the amount of communication activity • most frequently accessed data are most easily accessed • eliminating unnecessary sharing among relative independent program parts • object oriented languages explicitly identify the most intimate pieces of code and data and facilitates decision about placement and separation

6. Interaction primitives • Interaction between two objects involves • one object sending a message • one (or more) objects receiving the message • There may be more that one construct provided to send or receive messages in a given language • Constructs may be • synchronous (causing the process to block until some message related event occur) • asynchronous (allowing the object to continue processing when the message construct is executed locally)

7. Message constructs • The character of concurrent languages is determined by • the set of sending and receiving constructs • the way these constructs interact • Four possible sets of constructs covering the major design approaches that have been taken (pages and figures are missing....) • asynchronous message passing • .......... • non-blocking remote procedure call • future rpc

8. Encapsulation • Ideally objects maintain their own local state and state is only accessible by its own local methods • Synchronization problems: • class variables violates this principle • method lookup can also be viewed as class variable access • scoping rules and block objects

9. Class consistency • Object migration and independent redefinition can cause class inconsistency • If objects do not migrate and creation requires existence of appropriate class objects at the same node, then objects are guaranteed to be consistent • If object migration is allowed, it is possible for an object to migrate to a node with an incompatible or missing class object • The proper approach is to work with a system wide class hierarchy

10. The Actor Model (i) • Everything in a system is taken to be an actor • Actors are completely independent on other actors • All actions taken by an actor upon receipt of a message are concurrent, no implicit serial ordering of the actions in a method • Actors are characterized by an identity and a current behaviour • Actors may be partitioned into primitive and non primitive classes

11. The Actor Model (ii) • Non primitive actors have • an identity represented by a mail-address • current behaviour composed of a set of acquaintances (instance variables or local state) and a script defining the actions that an actor will take upon receipt of a message • Message passing is nonblocking and asynchronous using a mail-queue • All message sends are concurrent

12. Issues • The actor model does not define any model for code sharing • Delegation can provide some of the effects of sharing that inheritance can provide

13. Other approaches

14. Concurrent Smalltalk • synchronization by various forms of message passing • asynchronous message passing; anObject aMess & • Cbox Objects ; an intermediary that serve as a synchronization point for two asynchronously communicating objects • NonBlocking reply ; an object is allowed to reply to a sender without terminating the execution of the enclosing method • atomic objects behaves as serialized resources • Secretaries is another method for serialized execution, with a secretary object responsible for suspending and reactivating methods

15. Dally’s Concurrent Smalltalk • Asynchronous message passing • a form of future rpc that permits multiple requests to be send • Lock variables and locking • defined in the class an instantiated per-instance • the method defines the set of locks that it requires and the set it excludes • Distributed objects • multiple constituent objects with the same behaviour but with possibly different local data • message is sent to the logically distributed object but fielded by one of the constituent objects

16. Other approaches • Orient84/K • combines a Smalltalk-like object oriented model with a Prolog-style deductive execution mechanism • POOL-T • strongly typed concurrent object-oriented language