Concurrent object oriented programming languages
1 / 16

Concurrent Object-Oriented Programming Languages - PowerPoint PPT Presentation

  • Uploaded on

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

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about ' Concurrent Object-Oriented Programming Languages' - otylia

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Introduction i
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
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
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
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 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
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


  • 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
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
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
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


  • The actor model does not define any model for code sharing

  • Delegation can provide some of the effects of sharing that inheritance can provide

Concurrent smalltalk
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
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 approaches1
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