Concurrent Object-Oriented Programming Languages Chris Tomlinson Mark Scheevel

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

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

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

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

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)

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

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

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

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

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

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

Other approaches

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

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

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