Concurrent ObjectOriented 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
Dallys 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