Concurrency Distribution and Parallelism

in Ob jectOriented Programming

JeanPierre BRIOT

Lab oratoire dInformatique de Paris UPMC

JeanPierreBriotlipfr

Rachid GUERRAOUI

Departement dInformatique Ecole Polytechnique Federale de Lausanne

guerraouidiepflch

KlausPeter LOHR

Institut fur Informatik Freie Universitat Berlin

lohrinffuberlinde

Technical Report B

December

Abstract

This pap er aims at classifying and discussing the various ways along which

the ob ject paradigm is used for concurrent systems We distinguish the li

brary approach the integrative approach and the reective approach The

library approach applies ob jectoriented concepts as they are to structure

concurrent systems through libraries The integrative approach consists in

merging concepts such as ob ject and activity message passing and transac

tion The reective approach closely integrates proto col libraries and ob ject

oriented languages We discuss and illustrate each of these approaches and

p oint out their complementary levels and goals We will also make a careful

distinction b etween the notions of concurrency on the one hand referring to

the nonsequential semantics of a program and paral lelism and distribution

on the other hand referring to the actual implementation of a concurrent

system

message passing paral Keywords Ob ject ob jectoriented concurrency

lelism distribution transp osition application libraries integration reec

tion classication combination

Freie Universitat Berlin

Institut fur Informatik

Takustrae

D Berlin Germany

httpwwwinffuberlinde

Intro duction

It is now widely accepted that the ob ject paradigm provides go o d foundations for

the new challenges of parallel distributed and op en computing Ob ject notions

ro oted in the data abstraction principle are strong enough to structure and encap

sulate mo dules of concurrent computation whereas the notions are exible enough

to matchvarious granularities of software and hardware architectures

Most ob jectoriented programming languages do have some concurrency exten

sions or libraries and almost every new architectural development in the distributed

system community is to some extent ob jectoriented For instance b oth the Op en

Distributed Pro cessing ODP and the Ob ject Management Group OMG stan

dardization initiatives for heterogeneous distributed computing are based on ob ject

concepts

As a result many ob jectoriented mo dels languages and architectures for con

current parallel and distributed systems have b een prop osed and describ ed in the

literature Towards a b etter understanding and evaluation of these prop osals this

pap er addresses the question of how ob ject orientation and concurrency can be ac

commo dated in a common framework Rather than presenting an exhaustive study

of relevant systems this pap er aims at extracting classifying and discussing the

various ways the ob ject paradigm is used in those systems

Three approaches to concurrency

library approach the integra A coarse classication identies three approaches the

tive approach and the reective approach

Using the library approach concurrency features are added to a sequential ob ject

oriented mo del through libraries For example library classes for pro cesses sema

phores messages etc can be provided The language prop er is not changed

The integrative approach aims at unifying concepts of concurrency and of ob ject

orientation either by extending an existing sequential language or by designing

a new language Concepts of ob ject orientation and concurrency are merged For

example merging the notions of process and object gives rise to the notion of active

turn implies a unication of the notions of message passing and object and this in

invocation However integration is not always that smo oth we will see that concepts

may be in conict notably inheritance with synchronization and replication with

communication

The reective approach integrates proto col libraries within an ob jectoriented

programming language The idea is to separate the application program from the

various asp ects of its implementation and computation contexts mo dels of com

putation communication distribution etc which are describ ed in terms of meta

programs Reection may also deal with resource management such as load bal

ancing and time dep endencies and describ e it with the full p ower of a programming

language The reective approachmay b e considered as a bridge b etween the two

previous approaches as it helps to transparently integrate various computing proto

col libraries within a programming languagesystem Moreover it helps to combine

the two other approaches by making explicit the separation of and the interface

between their resp ective levels ie the integrative approach for the end user and

the library approach for developing and customizing the system

Although these approaches seem to comp ete at a rst glance they are in fact

complementary The library approach is oriented towards systems programmers

and aims at identifying required concurrency concepts and casting them into library

classes The integrative approach is oriented towards application programmers and

aims at dening a highlevel programming language supp orting a powerful concur

rent ob ject mo del The reective approach do es not take sides Its main goal is

to provide the basic infrastructure to enable dynamic system customization with

minimal impact on the application programs The success of a reective system re

lies b oth on a highlevel programming language and on a rich library of concurrency

abstractions

Parallel and distributed implementation of concurrency

We will make a careful distinction between concurrent paral lel and distributed

There are dierentways of running a concurrent program on an execution platform

The program may b e executed on a unipro cessor eg using a threading system or

on a parallel computer or even on a network of computers Thus while concurrency

is a semantic prop erty of a program parallelism and distribution p ertain to its im

plementation as determined by the compiler and other systems software Regarding

distribution the notion of distribution transparency is often used to emphasize the

in the program text fact that the distributed implementation is not reected

We will therefore be reticent with notions such as parallel program or dis

tributed program and rather sp eak of paral lel andor distributed implementation of

a concurrent language or program We feel that only if the underlying parallel andor

distributed system architecture is somehow reected in the program text defeating

transparency the program can justiably b e called parallel or distributed

It should be kept in mind that distribution do es not necessarily imply concur

rency a purely sequential program may be executed across machine b oundaries

using remote pro cedure calls A similar situation is found with clientserver sys

tems while a server mayormay not b e concurrent its clients rarely are only when

we view a server and its clients as one system we see a concurrent system op erating

in a distributed fashion

Activ e vs passive ob jects

What kind of relationship exists b etween the notions of process as used in traditional

concurrent programming and object There are several p ossible answers to this

question ranging from they are unrelated to they are just synonyms For swift

intro duction of concurrency into an existing ob jectoriented language the rst answer

may seem the natural one An Ada programmer however knowing that an Ada

task is both a pro cess and an invokable ob ject might prefer the second answer

Transplanting the Ada task concept into the ob jectoriented world gives rise to

active objects as opp osed to the common passive ob jects used in purely sequential

will see one of the distinguishing features of ob jectoriented programming As we

an active ob ject its indep endent activity actually comes in dierent avors For

example the ob ject may start its activityspontaneously as in Ada or it mayhave

to be triggered by an invo cation it may feature one thread of control as in Ada

or it may have several threads

Note that in principle the particular choice of an active ob ject mo del will be

indep endent of whether that mo del is implemented in a library or employing sp ecial

language constructs or using reection In reality the more interesting active ob ject

mo dels are found in integrative systems for reasons to b ecome clear below

Previous work

The reader is assumed to be familiar with traditional concurrency concepts as de

scrib ed eg in Andrews It should also be kept in mind that ob jectbased

concurrent programming is a wellestablished discipline which is supp orted by many

languages Ada is a wellknown example Ada Barnes SR although less

known features versatile and powerful constructs AndrewsOlsson Emerald

has b ecome known for its distribution supp ort Jul et al

Combining concurrency with ob ject orientation prop er ie including inheri

tance has b een the sub ject of many research pro jects since Several new lan

guage designs representing the in tegrative approach are discussed and compared

in Papathomas and Papathomas An early b o ok featuring dierent articles

on concurrent ob jectoriented programming is YonezawaTokoro a more recent

one is Agha et al For workshops on the sub ject the reader is referred to Agha

et al Agha et al Tokoro et al Guerraoui et al Ciancarini et al

Briot et al

Much eort has recently been put into C variants and libraries for parallel

pro cessing For a collection of articles ab out dierent pro jects on C and paral

lelism see WilsonLu

As mentioned ab ove our treatment of concurrent ob jectoriented programming is

not meant as an exhaustive study of the relevant programming languages A fairly

complete survey as of fo cusing on parallelism and including an annotated

bibliography can be found in Philippsen ab

The Library Approach

The basic idea of the library approachistouse encapsulation and abstraction and

p ossibly also classes and inheritance as structuring to ols for concurrency mecha

nisms imp orted from a certain execution platform This should facilitate the con

struction of concurrent systems using an ob jectoriented metho dology and a given

sequential ob jectoriented language

To illustrate the approach we survey the following examples the Smalltalk

programming language and environment where a basic and simple ob ject concept

is uniformly applied to mo del and structure the whole system through class libraries

including concurrency and distribution asp ects the Eiel programming language

b een prop osed to address concurrency C for which several libraries have

whose widespread use has resulted in a proliferation of concurrency libraries We

will also briey mention concurrency supp ort in ob jectoriented op erating systems

such as Choices and Peace

Smalltalk

Smalltalk is often considered as one of the purest examples of ob jectoriented

languages Goldb ergRobson This is b ecause its motto is to have only a few

concepts ob ject message passing class inheritance and to apply them uniformly to

any asp ect of the language and environment One consequence is that the language is

actually very simple its richness comes from its set of class libraries They describ e

and implementvarious programming constructs control structures data structures

etc internal resources messages pro cesses compiler etc and a sophisticated

programming environment with integrated to ols browser insp ector debugger etc

Standard class libraries

such as lo op and conditional are not In Smalltalk even basic control structures

primitive language constructs but just standard metho ds of standard classes which

make use of the generic invo cation of message passing They are based on b o oleans

and execution closures blocks Blo cks represented as instances of class Block

Context are essential for building various control structures that may b e extended

as required They are also the basis for multithreaded concurrency through pro

cesses Standard class Process describ es their representation the asso ciated meth

ods implement pro cess management susp end resume adjust priority etc The

pro cess scheduler is the single instance of the class ProcessorScheduler Smalltalk

pro cesses are implemented using coroutines or threads

Object

Collection

SequenceableCollection

Link LinkedList

ProcessorScheduler Process Semaphore

Figure Concurrency in Smalltalk The inherits from relationship

The basic synchronization primitive is the semaphore represented byclassSema

phore Standard libraries also include higher abstractions class SharedQueue to

manage communication between pro cesses and class Promise for representing a

value still b eing computed by a concurrently executing pro cess

Smalltalk also oers libraries for remote communication using so ckets and RPC

and for storage and exchange of ob ject structures supp orting marshaling p ersis

tence and transactions The Binary Object Streaming Service BOSS library pro

vides a basic supp ort for building distribution mechanisms

Extending class libraries

Due to Smalltalks uniform approach concurrency concepts and mechanisms are

well encapsulated and organized in a class hierarchy Thus they are b etter under

standable than if they were just a set of primitives in the programming language

It is also relatively easy to build more sophisticated abstractions on top of the basic

standard library

Mailer

Bcast

Rbcast Cbcast Abcast Arpc

Figure Communication in GARF The inherits from relationship

Inheritance has b een used extensively to structure various services for concur

rent programming An example is the Simtalk platform Bezivin which im

plements and classies various synchronization and simulation abstractions Hoare

monitors Kessels monitors p essimistic or optimistic simulation ob jects etc on top

of Smalltalk standard abstractionsclasses For distributed and faulttolerant pro

gramming abstractions an example is the GARF pro ject Garbinato et al in

whichtwo complementary class hierarchies have b een develop ed for various commu

nication mo dels p ointtop oint multicast atomic multicast etc see Figure and

ob ject mo dels monitor p ersistent replicated etc The HP Distributed Smal ltalk

pro duct provides a set of distributed services following the OMG CORBA standard

OMG also implemented as Smalltalk class libraries

In a similar approach for the Beta programming language Lehrmann Madsen

et al a library of classes named patterns in Beta for distributed pro

gramming has been develop ed BrandtLehrmann Madsen For instance class

NameServer represents a name server which maps textual ob ject names to physical

references Class ErrorHandler manages partial errorsfaults of a distributed sys

tem This approach enables the programmer to add distributed features to a given

sequentialcentralized program without changing the program logic ie through

additions rather than changes

Eiel

While Smalltalk is unt yp ed or at least not statically typ ed Eiel Meyer is

a language with static typing Originally designed as a sequential ob jectoriented

language it has b een extended towards concurrency in dierent ways Language

extensions prop er will be considered later Here we concentrate on the library ap

proach to Eiel concurrency

Existing concurrency libraries for Eiel demonstrate that there are fundamen

tally dierentways to mo del an indep endent activity pro cess task thread etc as

an ob ject We observe that two kinds of data b elong to a pro cess application data

and management data they can be either

separated a pro cess ob ject encapsulates data and op erations just for manage

ment of the pro cess the executed co de is resp onsible for its application data

and any interpro cess communication

integrated a pro cess ob ject encapsulates b oth management and application

co de and data consequently all pro cess management and interpro cess com

munication is p erformed through the ob jects interface wethus haveanactive

object in the sense of

Be careful not to confuse the ob jectpro cess integration leading to active ob jects

with what we have dened as the integrative approach they are indep endent of

each other In fact as we will see later either of the three approaches library

integrative reective can accommo date b oth ob jectpro cess separation and ob ject

pro cess integration

Separation is the basis of the Smalltalk solution A corresp onding variant for

discuss an integrated solution pre Eiel is describ ed in ColinGeib We will

sented in KaraormanBruno for Eiel the precursor of the current version of

Eiel

If a class inherits from the library class Concurrency its ob jects are active ob

jects The b ehaviour of an active ob ject resembles that of an Ada task its op

erations corresp onding to the Ada task entries Essentially the ob ject executes a

lo op checking for and accepting p ending invo cations As opp osed to Ada service

execution is always asynchronous results if any are returned using futures which

are similar to the promises mentioned in Halstead The programmer of

an active ob ject class is resp onsible for redening the routine scheduler inherited

from Concurrency scheduler must contain the lo op that controls the behaviour

of the ob ject

A simplied example is shown in Figure Active Printer ob jects are capable

of asynchronously executing print requests Note that Printer do es not exp ort

print Concurrency exp orts remoteinvoke among others and it is this op er

ation that has to be called by a client as shown remoteinvoke is implemented

as sending a message which is then picked up by a separate pro cess executing the

neverending scheduler

We see that this technique do es not achieve a fully transparent solution that

would allow the same syntax for invoking active and passive ob jects pprintarg

So although the system achieves more than just supp orting passive Process ob jects

it also exhibits problems with the library approach The sub ject is discussed in detail

in KaraormanBruno a metho dology for alleviating the problems is suggested

CLASS Printer

INHERIT Concurrency REDEFINE scheduler

FEATURE any attributes are declared here

printfilename String IS END print

scheduler IS LOCAL fn String

DO FROM getrequest UNTIL false

LOOP currentrequest requestqueueremove

fn currentrequestparameters ite m

printfn END loop

END scheduler

END Printer

in a client class

p Printer

premoteinvokeprint args

Figure Denition and usage ofaclass for active ob jects

The designers of the system have decided to implement active ob jects as Unix

heavyweight pro cesses rather than lightweight threads So invo cation of an active

ob ject alw ays involves Unix interpro cess communication This makes the approach

unsuitable for medium to smallgrain concurrency and highly parallel computation

It is readily usable though for physical distribution on platforms that supp ort

remote pro cess spawning

Highly parallel computation is supp orted by the EPEE system Jezequel b

EPEE follows the SPMD single program multiple data approach to data paral

lelism large data aggregates such as eg matrices are divided into fragments

The fragments are distributed together with replicated co de over the CPUs of a

multicomputer each CPU op erates on its data fragment comm unicating with the

other CPUs as necessary The essentials of EPEE are

A data aggregate is an Eiel ob ject Its interface is given by an Eiel class

The class however describ es the implementation of a fragment not that of

the complete aggregate

Such a class for distributed aggregates must be designed as a sub class of a

given nondistributed class say Matrix and the library class DISTAGG

The original op erations of Matrix have to b e redened Their implementation

has to b e mo died in suchaway that up date op erations in the co de are applied

to the lo cal fragment only DISTAGG manages the required interfragment data

exchange on remote read op erations and provides various supp ort functions

such as fragment sp ecic index mapping

Note that there is no explicit pro cess creation nor any visible message passing

The fragments of a distributed ob ject op erate concurrently each with its own

thread of control If each fragment is placed on a CPU of its own invoking the

ob ject causes all the fragments to start op erating in parallel

EPEEs ideas are close to other ob jectoriented approaches to massive paral

lelism notably those of Concurrent Aggregates Chien a and Charm

KaleKrishnan We will come back to these in section EPEE is not as

elegant but this may be the price that had to be paid for not changing the lan

guage

C

As opp osed to Smalltalk and Eiel C Stroustrup is not genuinely ob ject

oriented It is an ob jectoriented extension of C a language originally designed for

systems programming Thus it is not the ideal vehicle for building ob jectoriented

applications Nevertheless it has become the most widely used ob jectoriented

language and it is the language for ob jectoriented systems programming

This implies that combining C with concurrency libraries is more than a mar

riage of convenience As explained in the systems programmer needs exibility

and therefore prefers libraries to builtin features He also likes to exploit the low

level concurrency mechanisms oered by the underlying execution platform As the

a given platform to be wrapp ed in library approach allows for any functionality of

C functions or classes it is not surprising that there is a wide variety of concur

rency mechanisms cast in C libraries In fact any programmer can readily build

wrapp ers for concurrency mechanisms from her or his favourite platform

Threading libraries

Class libraries can be built for all kinds of pro cess concepts heavyweight or light

weight and for their corresp onding synchronization mechanisms Wehave seen how

concurrency can b e added to Eiel byproviding a library class Concurrency whichis

implemented using a heavyweight Unix pro cess Many concurrent programs how

ever are conveniently implemented using a threading system eg network servers

interactive programs parallel programs So it is imp ortant to lo ok in to ob ject

oriented threading libraries

Is a thread an ob ject While dening classes for synchronization ob jects such

as semaphores is a straightforward exercise it is not obvious how to cast a thread

abstraction into a class There are at least three dierent ways dep ending on how

the activity of a thread ob ject is describ ed

A thread is an instance of a sub class of Thread and its activity is describ ed by

the constructor of the sub class This is akin to the Simula approach to corou

tines the body of a coroutine class describ es both initialization and activity

of a coroutine ob ject

Again a thread is an instance of a sub class of Thread but its activity is

describ ed by overriding a special method similar to the scheduler routine in

A thread is an instance of Thread and its activity is describ ed by a function

that is passed as a parameter to the constructor or a sp ecial metho d

In all these approaches creating a thread ob ject spawns a new thread Note that

the lifetime of its activity may be shorter than the lifetime of itself as an ob ject

Also note that although a thread ob ject is active in a way b ecause the thread is

executing some co de it is not an active object

An example of approach is found in the coroutine library part of Suns C

library Sun The library oers a class task not Thread A task ob ject is

implemented as a coroutine ie with nonpreemptive scheduling There is also a

handler that allows to catch Unix software interrupts signals class Interrupt

Typical op erations on tasks are result wait for termination rdstate get

state etc Synchronization is supp orted by lowlevel wait op erations and by ob ject

queues

class producer public task

public

producer

compute x

resultisx

int main

producer p

compute y

cout Results are presult and y

return

Figure Typical scenario for thread ob jects customized Sun C task ob ject

Figure shows a fragment of a simple program using the coroutine library

The main program by declaring the ob ject p creates a task which executes the

producer constructor There is no interaction between parent and child task

except that the child terminates with pro ducing a result whichispicked up by the

parent

An example of the third approach sketched ab ove is found in PRESTO a sys

tem for parallel programming on a multipro cessor Bershad et al A newly

created thread is idle until explicitly started The function to be executed and its

or synchronization parameters are passed as parameters to the start op eration F

PRESTO features atomic integers and lo ck monitor and condition classes

The function to b e executed is passed to the constructor in DC SchillMo ck

a system for distributed execution of C programs on top of DCE the OSF

Distributed Computing Environment OSF Rosenb erry et al While DC

fo cuses on distribution it do es oer a few classes for concurrent programming Con

currency is implemented using the DCE threading subsystem Thus DC is

readily p orted to any system that is equipp ed with the DCE platform The DC

library includes a class Thread as describ ed ab ove plus a few classes for synchro

nization Parameters of the Thread constructor allow the user to cho ose among

dierent scheduling p olicies

An example that is typical for C exploiting overloading and templates is

the threading library of the ACE system Schmidt ACE stands for Adaptive

Communications Environmen t it is a to olkit for developing communicationoriented

software One of the goals of the ACE threading library is to present abstractions

that subsume the threading mechanisms of dierent platforms POSIX Solaris

Win thus enhancing p ortability

ACE has classes Mutex Semaphore RW Mutex and others for synchronization

A class template Guard is parametrized with a lo ck class eg Mutex A guard

ob ject acquires and releases a lo ck up on initialization and nalization resp similar

to a PRESTO monitor ob ject thus declaring a guard in a blo ck will turn this blo ck

into a critical region Note that ACE guards have nothingtodo with the Bo olean

expression guards used in genuinely concurrent languages

typedef void THRFUNCvoid

class Thread

public

static int spawnTHRFUNC fun create thread to execute fun

void arg with argument arg

long flags

threadt

void stack

sizet stacksize

hthreadt thandle to be referred to by thandle

static int suspendhthreadt suspend thread

static void exitvoid status terminate current thread

more routines

Figure Threads are not ob jects in ACE

Threads are handled on a very low level of abstraction in ACE There do es

exist a class Thread but this is just a package of static functions such as spawn

join yield etc abstracting from the idiosyncrasies of the threading functions of

Manager do es serve POSIX Solaris and Win Figure Another class Thread

the purp ose of creating and using thread manager ob jects they are resp onsible for

managing groups of threads spawning new memb ers disp osing of a thread when it

terminates etc But there is no class that would resemble Smalltalks Process or

the task from Figure

A relatively highlevel concept in ACE is the Task class This class must not

be confused with Suns task class mentioned ab ove Task is an abstract class

whose interface is designed for use according to the StreamMo dule concept for

layered communication Sub class ob jects of Task can participate in a batch of

mo dules implementing a stream either as passive or as active ob jects the latter

are asso ciated with their o wn threads of control Each task must provide a put

op eration to b e invoked from an adjacent mo dule in a stream and an svc op eration

service for asynchronous execution of the invoked service in case of an active

task ob ject

Task OO concurrency Thread Mutex Semaphore Unified threading API OS Different threading APIs

POSIX Solaris2 Win32

Figure Architecture of the ACE concurrency library

Figure shows part of the layered architecture of the ACE concurrency class

library Portability of the concurrency classes is achieved through a class OS that

just packages threadingrelated functions hiding the p eculiarities of dierent native

threading systems

Distribution supp ort

We have seen that for C the library approach tends to mirror the functionality

of the underlying execution platform This is true not only for concurrency but also

for distribution So we often nd library classes that encapsulate message passing

mechanisms such as ports or sockets eg ACE supp orts Unix so cket ob jects

This is unfortunate b ecause the ob ject invo cation paradigm is lump ed together

with the message passing paradigm of distributed computation In many cases it is

also not necessary b ecause remote invocation would be the mechanism of choice it

hides message passing and achieves distribution transparency in a genuinely ob ject

oriented program Remote ob ject invo cation the ob jectoriented analog to remote

pro cedure call is a technique that do es not require either changes in the language

or explicit usage of libraries

The DC system mentioned ab ove supp orts remote ob ject invo cation Note

DC however that distribution and concurrency are not strictly orthogonal in

Remote invocation comes in two avours synchronous and asynchronous where

asynchrony leads to truly parallel execution of client and server Asynchronous

invo cation of lo cal ob jects however is not directly supp orted Ironically this implies

that it is easier in DC to write a distributed concurrent program than to write

acentralized one

The most prominent platform for ob jectoriented distributed computing is CORBA

OMG MowbrayZahavi Although CORBA is languageindep endent the

bulk of supp ort available for CORBA to day is geared towards C Concurrency is

not a central issue in CORBA But implementors of server ob jects mayofcoursebe

confronted with the need for concurrency control Therefore an ob ject transaction

service and a nontransactional concurrency control service are provided

Parallel Computing

The challenge of ob jectoriented programming for parallel computing systems is to

nd an ob ject mo del that ts in with the preferred mo dels for parallel computation

For a librarybased solution there is no choice the ob ject mo del is given by the

sequential language Here the most straightforward path to parallel pro cessing is

executing the programs describ ed in on a sharedmemory multipro cessor just

as mentioned ab ove for PRESTO This pro duces functional parallelism but no data

parallelism

We have seen that EPEE uses Eiel ob jects to represent fragments of data ag

gregates also called collections for dataparallel programming A dierent way

of accommo dating the notions of ob ject and aggregate is to simply identify them

A p opular technique is to provide library classes for certain kinds of aggregates

hiding fragmentation and communication This of course leaves the programmer

with a limited set of predened aggregate classes But still a go o d degree of ex

achieved in C by using templates The Amelia Vector Template ibility can be

Library AVTL Sheer is an example of library supp ort for parallel pro cessing

of vectors

While an approachlikeAVTL is tailored towards a sp ecic class of applications it

has the advantage of hiding communication from the programmer If we are willing

to pay the price of lowlevel messagebased programming unlimited exibility is

achieved by libraries that connect to a communication platform eg MPI Skjellum

et al Libraries of this kind can b e seen as the distributedparallel equivalent

to threading libraries as describ ed ab ove

Ob jectoriented op erating systems

Choices Campb ell et al is a generic op erating system it was designed to be

easily p orted onto various machines but also to b e adjustable to various character

istics of both hardware resources and application interfaces such as le format

communication network and memory mo del shared or distributed An ob ject

oriented metho dology is presented together with the system both for the design of

distributed applications and for the design of new extensions to the Choices kernel

A sp ecic C class library has b een develop ed for Choices For instance class

ObjectProxy implements remote communications b etween ob jects classes Memory

Object and FileStream represent memory management and class ObjectStar

provides some generalized notion of pointer Class ObjectStar provides trans

parency for remote communications without need for a precompilation step This

class is also useful for the automatic garbage collector Class Disk abstracts and

encapsulates a physical storage device which may be instantiated eg in class

SPARCstationDisk when p orting Choices onto aSPARC station

The exp erience of the Choices pro jects shows that a distributed op erating system

develop ed with an ob jectoriented metho dology and programming language helps

at achieving b etter genericity and extensibility

Distributed memory multicomputers are the target of the Peace parallel op er

ating system SchroderPreikschat Peace is actually a family of ob jectoriented

op erating systems Its comp onents implemented in C can be congured in

dierent ways in order to t dierent hardware platforms and oer varying func

tionality

Peace makes heavy use of inheritance in implementing the system family concept

Astepwise b ottomup design of minimal extensions using sub classes results in a ne

grain inheritance hierarchy Exploiting this scheme application programs interface

to the op erating system by simply extending certain system classes

The basic unit of concurrent execution the threadisintro duced through a series

of abstractions Most threads are made up from two ob jects of classes native

and thread resp ectively The class native describ es the kernellevel part of the

thread thread refers to the userlevel part An application program can declare

a sub class of thread say custom redening the metho d action inherited from

thread Creating a custom ob ject causes the creation of a thread that executes the

redened action The situation is not unlike the one describ ed in with

the same caveat a thread is not an active ob ject contrary to the terminology in

Peace b ecause there is no provision for communicating with the thread through the

custom interface coroutine

notice points associate gate native

thread

custom

Figure Small excerpt from the architecture of Peace simplied inherits from

pro ceeds bottomup and uses pro ceeds lefttoright

Figure shows an excerpt from the architecture of Peace There is a sequence

of abstractions implemented through inheritance that leads from coroutine to

native The associate part of a userlevel thread refers to a gate ob ject that

knows the unique identier of the kernellevel thread

Threads interact either via shared ob jects or if lo cated in dierent address

spaces through message passing Intraaddressspace thread synchronization is

achieved via event counters which are supp orted by notice A variety of message

passing mechanisms is supp orted

In search for standard abstractions

The main issue underlying the library approach is the design and implementation of

adequate abstractions on top of whichvarious higherlevel concurrency abstractions

can be builtina convenient way

One of the most signicant examples for concurrent programming is the semaphore

abstraction which through a welldened interface wait and signal op erations

and a known b ehavior metaphor of the train semaphores represents one stan

dard of synchronization for concurrent programming Such a basic abstraction

may be used as a foundation to build various higherlevel synchronization mech

anisms as eg the Guard class of ACE Classication and sp ecialization mecha

nisms as oered by ob jectoriented programming are then appropriate to organize

such a libraryhierarchy of abstractions as for instance in the the Simtalk platform

Sect Peace is a typical example for an extremely careful design of a hierarchy

of thread abstractions

An example of developing concurrency abstractions complementary to program

abstractions can be found in the Demeter environment Lop esLieb erherr The

two lo osely coupled dimen abstract sp ecication of a program is decomp osed into

sions the structural blo ck which represents relations between classes and the

b ehavioral blo ck which describ es the op erations A third dimension has recently

b een added the concurrency blo ck which describ es the abstract synchronization

patterns between pro cesses The abstract sp ecications and the relative indep en

dence between these three comp onents help with the development of generic and

reusable programs

A similar study of abstractions for distributed programming has b een prop osed

in Black where decomp osing the concept of transaction into a set of abstrac

t concepts such as lock recovery and tions is suggested The goal is to represen

persistence through a set of ob jects that must be provided by a system in order

to supp ort transactions The mo dularityof this approach would help dening var

ious transaction mo dels adapted to sp ecic kinds of applications For instance

a computersupp orted co op erative application do es not need concurrency control

constraints as strong as those required for a banking application Both the Venari

Wing and the Pho enix GuerraouiSchip er pro jects aim at dening various

transactional mo dels from a set of minimal abstractions

Evaluation of the library approach

In summary the library approach aims at increasing the exibility yet reducing

the complexity of concurrent computing systems by structuring them as libraries

The former application requires strict serialization of transactions through a lo cking mechanism

while the latter do es not

of classes Each asp ect or service is represented byanob ject Such mo dularityand

abstraction ob jectives are very imp ortant b ecause concurrent computing systems

are rather complex and ultimately use very lowlevel mechanisms such as pro cessor

switching and network communication Furthermore such systems are often devel

op ed by teams of programmers having separate mo dules with welldened interfaces

is of prime imp ortance in such a context Finally the dicultywithmaintaining and

extending Unixlike systems is mainly due to low mo dularity and p o or abstractions

Although progress is being made towards that direction as noted ab ove it is

still to o early to come up with a standard class library for concurrent program

ming It may ev en be a red herring We need a go o d knowledge of the minimal

mechanisms and their interaction in addition we need a consensus ab out the de

sirable extensions and how to structure them Dierent technical communities are

involved p eople from programming languages op erating systems distributed sys

tems database sytems and last but not least realtime systems The fact that

the semaphore abstraction b ecame a standard primitive for synchronization is just

a tiny grain of hop e that a generally accepted library of concurrency abstractions

might emerge

Integrative Approach The

Wehave seen that the library approach to concurrent ob jectoriented programming

starts out from a given concurrency platform such as an op erating system or a

userlevel threading package The lowlevel concurrency mechanisms oered by the

platform are cast into ob jects Wherever p ossible inheritance is used as an aid in

structuring a concurrency library

This b ottomup approach although exible is not attractive for the applica

tion programmer If we follow the ob ject paradigm all the way down from anal

ysis through mo deling through design to implementation we would like to stay

on a problemoriented level Now the library approach do es help with the ob ject

oriented structuring of lowlevel mechanisms like threads semaphores messages

etc but those ob jects are not hidden they are kept separate from the ob jects

structuring the application In other words there is no integration b etween the two

tasks the programmer faces programming with application ob jects and managing

concurrency also with ob jects but not the same objects

Furthermore programming may b ecome cumb ersome when using libraries and

concurrency managementmay obscure the application logic For instance sub classes

class mentioned in give rise to active ob jects But in pro of the Concurrency

gramming such a class we are forced to manage explicit acceptance of invo cations

It would be more attractive to have a solution where classes for active ob jects are

not much dierent from regular classes

In summary rather than keeping application logic and concurrency management

separate we should strive for a solution that oers a unied ob ject mo del to the

programmer This cannot b e achieved through libraries An integrative approachis

necessary where concurrency semantics are built into the language either from the

agiven sequential language b eginning or by extending

Degrees of ob jectpro cess integration

The concept of active object which integrates the notions of ob ject and pro cess is

app ealing and natural it immediately o ccurs to us when we mo del reality But it

is not the only way of incorp orating concurrency into an ob jectoriented language

There is a varietyofways exhibiting dierent degrees of ob jectpro cess integration

No integration The language supp orts indep endent activities called pro cesses

threads tasks or whatever but these are not objects All ob jects are passive

and activities interact via shared and prop erly synchronized ob jects Exam

ples Mo dula Harbison Guide Decouchan t et al Balter et al

Beta Lehrmann Madsen et al pSather Feldman et al

Poor integration a Pro cess ob jects do exist but they are a sp ecies dierent

from class objects They are instantiated from certain pro cess templates which

do not participate in inheritance Example Concurrent C GehaniRo ome

Or b pro cess ob jects are instantiated from a builtin Thread class but

have no applicationsp ecic interface op erations on pro cesses are stop start

reschedule etc The semantics is very close to that of the library approach

describ ed in Example Java ArnoldGosling Lea

are two kinds of ob jects active and passive In Partial integration There

heritance among their classes is p ossible but sub ject to certain restrictions

Examples Eiel Caromel Charm KaleKrishnan

Ful l integration All ob jects are p otentially active and there are no restrictions

regarding inheritance Examples Pool Americavan der Linden CEiel

Lohr

This classication is a renement of the simple distinction made in the context

of the library approach in separated vs integrated handling of management

data and application data of a pro cess ob ject Note that integration in the sense of

is fully realized in aand

The integrative approach tries to integrate into the application ob jects not only

pro cesses but also synchronization For passive objects this is similar to rejecting

synchronization objects eg semaphores and instead using synchronized objects

eg monitors in traditional concurrent programming Active objects use synchro

nized invo cation similar to the Ada rendezvous In b oth cases however it is not

obvious how synchronization relates to inheritance It turns out that inheritance

may give rise to a phenomenon called inheritance anomaly We will return to this

later

Passive ob jects

There are rare cases where allowing several concurrent activities to access a given

passive ob ject cannot do any harm Examples are readonly ob jects or very small

ob jects where the op erations are implemented as indivisible machine instructions

eg increment an integer variable In most cases however shared ob jects in a

concurrentenvironmenthavetobesynchronized It is helpful to distinguish b etween

dierent sources of the need for synchronization

specication of the ob ject condition synchronization

implementation of the ob ject exclusion synchronization

scheduling of the op erations if dierent from builtin scheduling

We will discuss each of these in turn

Condition synchronization

The sp ecication of eg job queues would indicate that the op eration to remove a

job from a Queue can only b e executed under the precondition that the queue is not

empty Thus acceptance of a remove invo cation has to b e delayed when the queue

is empty

A problemoriented solution to this synchronization problem is to use a declar

ative guard ie a concrete version of the abstract precondition expressed as a

predicate over the ob jects data representation Figure upp er part with adho c

syntax Guards are wellknown in traditional concurrent programming and can

be found eg in Ada SR and Orca Bal et al Guards achieve the desired

integration b ecause they do not require any synchronization statements in the imple

mentation of the ob jects op erations Activities are blo cked or woken up implicitly

The price that has to be paid for this is p erformance explicit op erations such as

signalling a monitor event or a semaphore are more ecient

CLASS Queue

VAR length Natural

OPERATION remove Item

WHEN length

END END

END Queue

CLASS Queue IMPLEMENTS QueueType IS

METHOD removeOUT i Item

BEGIN END remove

CONTROL remove completedappend completedremove

END Queue

Figure Guarded remove op eration in class Queue

In the language Guide the guards are gathered in a central lo cation of the class

called the control clause see Figure lower part A guard can refer not only to the

ob jects state and the op erations parameters but also to counters which indicate

certain numb ers connected with op erations Rob ertVerjus eg completedop

is the number of completed executions of op

Referring to counters has the advantage of representation indep endence but may

have drawbacks when it comes to inheritance The guards in the control clause are

inherited and can be redened if necessary Figure shows a sub class of Queue

ExtendedQueue a new op eration delete for deleting the last element has been

added Notice that it do es not suce to add a new guard for delete to the control

clause Annoyinglywe have to redene the remove guard although remove itself is

not redened This anomaly is one example of a sp ecies of phenomena called inher

itance anomaly We will encounter more examples below A thorough treatment of

inheritance anomalies can be found in MatsuokaYonezawa

CLASS ExtendedQueue INHERIT Queue

OPERATION delete

WHEN length

BEGIN END END ExtendedQueue

CLASS ExtendedQueue SUBCLASS OF Queue IMPLEMENTS ExtendedQueueType IS

METHOD delete

BEGIN END delete

CONTROL remove completedappendcomple ted rem ove com plet edd ele te

delete completedappendcomple ted rem ove com plet edd ele te

END ExtendedQueue

Figure Inheritance anomaly when using counters

The expressivepower of counters is not very high Imagine weneedaClearable

Queue to be derived from Queue by adding a clear op eration There is no way to

express the new synchronization requirements by means of counters Fortunately

Guide do es not rely solely on counters the guards may also refer to the ob jects

represention If we derive our sub class from another version of Queue where the

control clause reads remove length we arriveatthe trivial solution shown in

Figure A solution for the ab ove ExtendedQueue is also very simple The lesson

to b e learned is try to avoid using counters for condition synchronization

Another highlevel approach to condition synchronization is to use synchroniza

tion expressions all information ab out synchronization is centralized in one ex

pression which sp ecies all p ossible histories sequences of op eration executions

of an ob ject This approach is attractive because a synchronization expression is

completely indep endent of the ob jects representation it is in fact part of the

sp ecication or derivable from it

Synchronization expressions are akin to path expressions Campb ellHab ermann

Because the original path expressions lack expressive power later versions

have been extended with predicates A predicate may again refer to counters as

mentioned ab ove Andler or it may be a guard referring to the ob jects state

van den BosLara The latter version obviously defeats what makes path

expressions attractive in the rst place

CLASS ClearableQueue INHERIT Queue

OPERATION clear

BEGIN END

END ClearableQueue

CLASS ClearableQueue SUBCLASS OF Queue

IMPLEMENTS ClearableQueueType IS

METHOD clear

BEGIN END clear

END ClearableQueue

Figure Statebased guards in sup erclass no inheritance anomaly

The biggest problem with synchronization expressions is that they do not blend

well with inheritance This is due to their centralized nature It is usually imp ossible

to inherit a synchronization expression and take new op erations in the sub class into

account by just making an incremental change to the synchronization behaviour

adding a new expression Thus redenition of the complete synchronization expres

sion is usually inevitable a grave inheritance anomaly

Exclusion synchronization

its Until now we have tacitly assumed that an ob ject is never invoked when one of

op erations is already executing However activities meeting at an ob ject are the

rule rather than the exception So the ob ject designer has to sp ecify the ob jects

behaviour under such circumstances The sequential sp ecication of the ob ject has

to b e extended to cop e with a concurrent environment

The simplest extension is to p ostulate serializability the eect of any concurrent

invo cation of op erations and their subsequent execution is equal to the eect of some

serial execution of the invo cations ie any order is acceptable Often this is to o

strong a requirement There are many cases where it is p erfectly acceptable that an

ob ject when placed in a concurrent environment may display a behaviour unseen

in a sequential environment

In any case the implementation usually has to employ synchronization mech

anisms to meet the sp ecication This kind of synchronization is called exclusion

synchronization or concurrency control Note that how to synchronize is highly de

p endent on the ob jects representation Complete mutual exclusion as known from

monitors guarantees serializability So do transactional lo cking schemes suchastwo

phase lo cking But even more lib eral synchronization measures are often sucient

when the sp ecication do es not require serializability

e approach calls for avoidance of explicit lo cking op erations the The integrativ

programming language should oer transactions or declarative constructs suitable

for sp ecifying exclusion Several languages are rather poor in this resp ect distin

guishing just b etween atomic objects with complete exclusion ie monitorlike and

nonatomic ob jects with no exclusion at all Some insist that all ob jects be atomic

an approach that is do omed to failure for the same reasons that make nested

monitors impractical

Nonatomic shared ob jects give rise to intraobject concurrency in addition to

the interobject concurrency which is present a priori due to the mere existence of

concurrent activities op erating on dierent ob jects We distinguish b etween dierent

degrees of intraob ject concurrency

Atomic object There is no intraob ject concurrency

Quasiatomic object Several activations of op erations may co exist but at most

one of them is not susp ended This is similar to a monitor using eventvariables

to susp end pro cesses

Semiconcurrent object There is true intraob ject concurrency but some re

strictions apply as sp ecied by the programmer

Ful ly concurrent object Concurrency within the ob ject is not restricted This is

the default for a normal sequential ob ject placed in a concurrent environment

We will often not distinguish between semiconcurrent and fully concurrent ob

jects just calling them concurrent ob jects

Exclusion can be sp ecied either per ob jectclass or per op eration The p er

ob ject approach lacks exibility and results in declaring ob jects either fully con

current or atomic While this may be considered restrictive even more restric

that intraob ject concur tive schemes have been suggested it has b een argued

rency should b e banished altogether b ecause reasoning ab out programs that contain

atomic ob jects only is much easier America Meyer

Most language designers have considered this to o severe a restriction It is com

mon to allow intraob ject concurrency and to tie the sp ecication of exclusion to

the op erations A typical device is the synchronized keyword in Java op erations

marked synchronized are mutually exclusive for the underlying ob ject or for the

underlying class if the op eration is a static metho d Actually synchronized

can also be used for establishing arbitrary critical regions Condition synchroniza

tion is handled using events another indication that Jav a favours a low degree of

integration

A language that allows for sp ecifying readerwriter exclusion is DistributedEiel

GunaseelanLeBlanc designed as a mo died Eiel for programming distributed

applications on top of the Clouds distributed op erating system An op eration can

be marked as accesses or modifies meaning that it has to acquire aread lo ckor

a write lo ck resp on the ob ject b efore it can execute If neither mark is present

no lo ck is acquired

This approach is generalized in another Eiel extension CEiel Lohr us

ing annotations to the op erations a binary symmetric compatibility relation among

the op erations of an ob ject can be sp ecied If op eration op is declared com

patible to op eration op b oth can be executed in an overlapping fashion Incom

patible op erations are mutually exclusive This approach can be traced back to

AndrewsMcGraw where a centralized parallel clause is used to sp ecify com

patibility in a precursor of SR Note that declaring compatibilities is safer than

declaring exclusion requirements

When a given sequential class without any annotations is used as a template

for shared ob jects these ob jects are atomic by default thus keeping their

sequential semantics

When a sub class extends the set of op erations of the sup erclass a new op era

tion is incompatible with all the inherited op erations unless explicitly stated

otherwise

The fact that exclusion synchronization is implementationdep endent and there

fore conceptually dierent from condition synchronization is recognized by some

though not all languages Guide employs counters not only for condition synchro

nization as mentioned ab ove but also for exclusion synchronization currentop

denotes the numb er of activities currently executing op so a guard op currentop

sp ecies that op excludes op though not the other way around Unfortunately

this approach is once more prone to inheritance anomalies Figure shows three

versions of a class Part given in Distributed Eiel CEiel and Guide resp A

CEiel annotation starts with the characters just like an Eiel comment but is

identied as an annotation by the next character The reader is invited to ll in

the missing co de

CLASS Part

EXPORT number text update

FEATURE number Integer IS

DO END

text String ACCESSES

DO END

updates String MODIFIES

DO END

END Part

CLASS Part

CREATION

FEATURE number Integer IS number

DO END

text String IS text number

DO END

updates String IS number

DO END

END Part

CLASS Part IMPLEMENTS PartType IS

CONTROL text currentupdate

update currentupdate currenttext

END Part

Figure ReaderWriter exclusion using Distributed Eiel CEiel and Guide

A sub class ClearablePart is shown in Figure It turns out that the Guide

version suers from an inheritance anomaly although text and update are not



redened their guards have to b e

CLASS ClearablePart INHERIT Part

EXPORT number text update clear

FEATURE clear MODIFIES

DO END

END ClearablePart

CLASS ClearablePart INHERIT Part

CREATION

FEATURE clear IS number

DO END

END ClearablePart

OF Part IMPLEMENTS ClearablePartType IS CLASS ClearablePart SUBCLASS

METHOD clear

BEGIN END clear

CONTROL text currentupdate currentclear

update currentupdate currentclear currenttext

clear currentupdate currentclear currenttext

END ClearablePart

Figure Exclusion synchronization and inheritance

in Distributed Eiel CEiel and Guide

A unique approach to concurrency control for shared passive ob jects is taken in

the parallel language Charm KaleKrishnan A few sp ecial builtin tem

plates for abstract classes supp ort concepts such as accumulator ob jects mono

tonic ob jects and others These concepts are dened by certain prop erties of the



It should b e mentioned that the currentversion of Guide supp orts the extension by logical

anding of an inherited guard So if we and assertions currentclear instead of summing up

the synchronization counters we can at least weaken the anomaly in this example

op erations A monotonic class MC eg mo dels ob jects that are mo died monotoni

cally with resp ect to some linear ordering through an update op eration By virtue

of b eing declared monotonic MC has a builtin op eration MonoValue that delivers

the currentvalue of the ob ject The programmer has to explicitly provide the op era

tion update that has to b e monotonic idemp otent commutative and asso ciative An

example is given in Figure a Max ob ject m would contain some currentmaximum

integer value which is up dated p erio dically using mupdatenew The current

maximum value is obtained by mMonoValue The necessary synchronization is

p erformed automatically and so is the replica maintenance of its distributed imple

mentation as explained b elow The programmer only supplies the problemsp ecic

data representation which must be a Charm message ob ject an instance of a

sp ecial recordlike message typ e and the update co de

message Integer int value

monotonic class Max

Integer object

public MaxInteger init

object Integer newmessageInteger

objectvalue initvalue

int updateInteger new

if objectvalue newvalue

objectvalue newvalue

return

return

Figure Simple monotonic class in Charm

Providing builtin solutions for several common synchronization problems rep

resents in a way the ultimate integration of synchronization The advantages are

obvious and so are the drawbacks if you need supp ort for something the language

designers did not plan for you may nd yourself building a simple mechanism out

of heavyweigh t constructs

Scheduling

There are two reasons why an ob ject might not accept an invo cation right when

it arrives condition synchronization and exclusion synchronization An invo cation

that has b een issued yet not accepted is said to b e pending Any synchronized ob ject

has an asso ciated queue of p ending invo cations

The natural strategy for handling this queue is FCFS if several p ending invo

cations b ecome eligible for acceptance they are accepted in the sequence of their

arrival This strategy is not necessarily fair as seen eg with the ReaderWriter

problem and it may not be in accordance with what the programmer wants The

situation can b e handled in either of two ways a the language designer ignores it

leaving the programmer with the task of designing separate scheduling ob jects which

implement the desired nonstandard strategy b ho oks are built into the language

that allowto refer to the p ending invo cations in appropriate ways

Most languages supp ort b if only in restricted form A p opular approach is to

use synchronization counters which as wehave seen are also used for condition and

exclusion synchronization Simple scheduling problems such as some ReaderWriter

variants can be solved in this way but synchronization counters are much to o

restrictive not allowing to takeinto account ob ject state op eration parameters and

invo cation time Figure shows another solution to the ReaderWriter problem

solved in Figure this time priorityisgiven to the writers by extending the text

guard with pendingupdate Note that exclusion issues and scheduling issues

are indiscriminately interwoven whichmay hamp er understanding and complicates

mo dication in sub classes

CLASS Part IMPLEMENTS PartType IS

CONTROL text currentupdate pendingupdate

update currentupdate currenttext

END Part

Figure Using synchronization counters

for b oth exclusion and scheduling in Guide

The language SR although not ob jectoriented oers a more p owerful construct

for scheduling invo cations of an op eration declared with a by clause are scheduled

according to the value of the integer expression given in that clause whichmayrefer

to parameters A exible solution that is even more powerful than SRs by has

been describ ed in McHale et al and Lohr scheduling predicates referring

to the p ending invo cations are used in guards Their expressivenes is strong enough

to allow for straightforward solutions of complex scheduling problems Figure

shows the Part example writer priority and an atomic shortestjobnext Printer

class

CLASS Part

FEATURE number Integer IS number

DO END

text String IS text number

REQUIRE

ALL update SAT false no pending updates

DO END

updates String IS number

DO END

END Part

CLASS Printer

FEATURE printf File IS

REQUIRE

ALL print SAT

printfsizefsize AND

printfsize fsize printRankRank

DO END

END Printer

Figure Scheduling predicates CEiel version

The examples are given in CEiel where a guard is marked by the delay annota

tion in Eiels precondition clause REQUIRE The universal quantier

in the guard of the op eration print uses a variable called print to o This implic

itly declared variable refers to the pending print requests represented as records

of invo cation arguments Rank is an additional record eld referring to the virtual

an invo cation Here it is used for FCFS ordering of jobs with equal arrival time of

size

Access to ob ject representation considered harmful

There is a p otential for subtle errors when synchronization and scheduling decisions

for an ob ject are based on those very variables that represent the ob jects state and

are mo died by the ob jects op erations The programmer has to b e aware of p ossi

ble conicts between guard evaluation and state manipulation Enhanced safety is

achieved by complete separation of instance variables and synchronization variables

McHale As the Printer example in Figure demonstrates all synchronization

information is centralized in a synchronization section of the class Synchroniza

tion variables actions and guards are declared here Several standard identiers are

used to refer to actiontriggering events such as arrival of an invo cation start of

an op eration etc Other identiers refer to synchronization counters such as exec

inv waiting etc and to certain constituents of a guard eg this

The rst line of the synchronization section declares an integer variable len of

which there will b e one instance per invocation of print The second line sp ecies

an action to b e taken when a print invo cation arrives get the length of the le to

be printed and store it in this invo cations len variable The remaining four lines

constitute the guard for print sp ecifying mutual exclusion in the rst conjunct and

shortestjobnext scheduling in the second conjunct

The synchronization variables approach lends itself naturally to the intro duction

of generic synchronization policies which can b e instantiated for dierent application

This can also mitigate the classes that need the same kind of synchronization

problem of inheritance anomalies in some though not all cases

class Printer

printString fileName

synchronization

int len local to print

arrivalprint thisinvlen get file length

print execprint and

thereisnop in waitingprint

plenthisinvlen or

plenthisinvlen and parrtimethisinvarrti me

Figure Synchronization variables

example shows one variable one action and one guard

Active ob jects

Invocation of a passive object works like a pro cedure call the calling activity enters

an op eration of the ob ject executes the op eration and returns An active object

however can have one or more indep endent threads of control asso ciated with it

lowlevel messagepassing primitives for interob ject communica Now intro ducing

tion would violate the spirit of integration It is preferable to keep the invo cation

paradigm and generalize it towards remote invocation as known from Ada It is

imp ortant to dierentiate between this notion of remote invo cation meaning ac

tive object invocation and the RPClike notion of remote invo cation intro duced in

as a distributed implementation technique for passive object invocation across

machine b oundaries

Ob ject bodies

Many designs for the active ob ject concept have b een inspired by the Ada tasking

mo del A task has its own thread of control Its body encapsulates state variables

and a statement sequence that b egins executing as so on as the task is created A

set of entries comparable to op eration signatures is asso ciated with a task A

remote invo cation lo oking like a pro cedure call refers to one of these entries

statements As opp osed to a passive ob ject however a task uses explicit accept

for accepting invo cations and executing the requested service Compare this to the

implicit acceptance in a passiveobject if a b o dy is present it is used for initialization

only and acceptance just means that one of the op erations starts executing



Concurrent C and Pool are typical representatives of this approach Weomit

Concurrent C b ecause of its lowlevel of integration APo ol class for active

Queue ob jects is shown in Figure The declarative part for lo cal data is omitted

Op erations such as METHOD enq are declared just like for passive ob jects A Queue

ob ject has a single thread of control Its activity is describ ed by the statements

enclosed in the BODYYDOB keywords DOOD is an innite lo op As opp osed to Ada



Actually there are three dierentversions of Pool Po olT Po ol and Po olI

the accept statements starting with the keyword ANSWER just refer to one or more

op eration names ANY meaning all op eration names

CLASS Queue

METHOD enqitem T

BEGIN cellputrearitem

rear rearMOD size END enq

METHOD deq T

BEGIN RESULT cellgetfront

postprocessing starts

front frontMOD size END deq

BODY defaults to DO ANSWER ANY OD

DO IF empty THEN ANSWERenq

ELSIF full THEN ANSWERdeq

ELSE ANSWER ANY FI OD YDOB

END Queue

Figure Active ob ject class in Pool

comments start with and end with line end

Several p oints have to b e noted

A queue is usually implemented as a passive ob ject as we have seen earlier

It is only for demonstration purp oses that we present an active queue And

it should be kept in mind that the body of a Pool class can of course be of

arbitrary complexity

The example do es exhibit tinybitsof indep endent activity

The caller of an op eration continues as so on as the op erations RESULT

statement has been executed Any statements following the RESULT are

executed by the ob ject which constitutes a kind of indep endent postpro

cessing The service is therefore partly asynchronous

The invo cation of an op eration without a result enq in the example re

turns immediately In this case the service is ful ly asynchronous

Notice that a missing b o dy defaults to

DO ANSWER ANY OD

This is Pools answer to the question of how to distinguish passive from ac

tive ob jects there is no such distinction All ob jects are conceptually active

Whether an ob ject without a body is implemented with or without a p erma

nen t thread is a matter of optimization in a centralized system and can be

left to the compiler Note however that b ecause of the singlethread semantics

those passive ob jects are atomic monitorlike not concurrent

An imp ortant observation is that in more complex cases the b o dy may describ e

both applicationsp ecic b ehaviour and the logic for accepting invo cations ie all

condition synchronization and scheduling not exclusion synchronization b ecause of



the atomicity The missing distinction among these very dierent issues and their

centralized handling in the body is the source of several problems with Pool The

language is highly prone to inheritance anomalies If Guides central control clause

was problematic Pools BODY is even more so b ecause it is imp erative rather than

declarative lacking the structure achieved by asso ciating guards with op erations

Figure shows the Pool version of the ClearableQueue wehave seen b efore There

is no way of reusing the b o dy of the sup erclass a complete redenition is required

Recognizing this Po ol requires that every class provide its own b o dy Thus inheri

tance anomaly is the rule rather than the exception except for the sp ecial case of

empty b o dies in b oth sup erclasses and sub class

CLASS ClearableQueue INHERIT Queue

METHOD clear

BEGIN front rear END clear

BODY DO IF empty THEN ANSWERenqclear

ELSIF full THEN ANSWERdeqclear

ELSE ANSWER ANY FI OD YDOB

END ClearableQueue

Figure Pool even avery simple sub class necessitates a new body

Asynchronous service and lazy synchronization

We have seen that Pool supp orts limited forms of async hronous service if there is

no result the client continues immediately after the call not even waiting for the

acceptance of the call and if there is a result client and server op erate concurrently

after the result has been returned p ostpro cessing

It is p ossible to decouple invo cation and waiting for a result Using futures as

surrogates for results that are yet to be computed asynchrony can be achieved

without resort to explicit message passing Only when the caller really needs the

result ie is going to op erate on it synchronization with the service provider is

required Integration of futures into the invo cation mechanism has the eect that

the strict synchronization inherent in synchronous invo cation is replaced with syn

chronization by need or lazy synchronization This technique was rst intro duced

in Eiel Caromel where it is known as waitbynecessity Eiel has a pre

dened class PROCESS Instances of a direct or indirect sub class of PROCESS are

de active ob jects The ob ject body is represented by a routine Live which has a

fault implementation in PROCESS and is usually redened in sub classes of PROCESS

comparable to Po ols BODY Several other routines inherited from PROCESS enable



This is not the whole story b ecause ANSWER statements can also o ccur in the co de of op erations

giving rise to quasiatomic ob jects

an active ob ject to control the acceptance of invo cations in its Live routine much

like it is done with ANSWER in Po ol

Eiel shares with Pool the prop erty that there are no concurrent ob jects

Passive ob jects do exist in Eiel any nonPROCESS ob ject is passive But these

ob jects cannot b e shared among active ob jects Ob jects are always passed byvalue

in remote invo cations ie the active ob ject receives a copy

server ActiveServer

result R

result serverserviceargs

client continues immediately

resultop synchronization is implicit

Figure Lazy sync hronization

Service execution is always asynchronous in Eiel If there is a result lazy syn

chronization takes eect In Figure the calling client may pro ceed immediately

after the invo cation b ecoming blo cked only when it tries to prematurely invoke the

result ob ject

Implicit acceptance

Wehave seen that controlling the b ehaviour of an active ob ject by a b o dy is fraught

with problems Fortunately active ob jects can also use implicit acceptance as known

from passive ob jects We not in passing that SR is a language where b oth implicit

and explicit acceptance can be used at the programmers discretion

Exclusive usage of implicit acceptance brings forth a restricted form of active

ob jects reactive objects they start op erating only when invoked Reactive ob jects

degenerate to passive ob jects if all op erations are synchronous

Reactive ob jects with asynchronous op erations only are supp orted by Charm

they are instances of sp ecial classes that start with the keywords chare class

Figure shows an exampleachare class featuring two op erations

message Message

chare class Printer

entry printwhiteMessage msg

printgrey Message msg

Figure A Charm class for reactive Printer ob jects

The op erations of a chare class must have exactly one argument which has to

beapointer to a Charm message Note that although the Printer class lo oks

passive a Printer ob ject is active and op erates concurrently with its clients if

only executing one op eration at a time Asynchronous invo cation without result

is semantically equivalent to asynchronous message passing and is in fact imple

mented with messages in Charm That the semantics is indep endent of explicit

vs implicit sendingreceiving is the essence of the wellknown duality principle of

pro cedureoriented vs messageoriented interaction LauerNeedham

Chare classes cannot b e used with condition synchronization nor do they allow

for synchronous op erations The reason is ecient distributed implementation see

b elow There is no conceptual reason however why condition synchronization

and discretionary synchronyasynchrony sp ecication should not go together In

fact CEiel allows a class Printer to b e written as shown in Figure Op erations

are synchronous by default as for passive ob jects but can b e marked asynchronous

using the asynchrony annotation v Guards are intro duced by the delay an

notation Note that foo is a guarded asynchronous op eration with lazy

synchronization

CLASS Printer

printf File IS v FEATURE

DO END

waitTrayEmpty IS

REQUIRE

sheets

DO END

foo T IS v

REQUIRE

DO END

END Printer

Figure A CEiel class for reactive Printer ob jects

Multithreaded ob jects

We have only considered atomic active ob jects by now each ob ject had a single

thread of control and so was not capable of intraob ject concurrency Rememb ering

the duality principle we see that dynamic invo cation hierarchies of singlethreaded

active ob jects are prone to the same pitfalls as nested monitors although the prob

lem is mitigated when using asynchronous invo cation

to the resources The more exible concurrent active ob jects can be traced back

of SR In addition to data and pro cedures an SR resource may encapsulate one or

more pro cesses Concurrency within a resource may result both from concurrent

pro cedure invo cations and from the activities of the resources pro cesses

In an ob jectoriented setting multiple static pro cesses in an ob ject would amount

to multiple b o dies using explicit acceptance Now in view of inheritance anomalies

if one such body causes problems multiple bodies would lead to disaster It is

therefore the cleanest solution to use only implicit acceptance ie pro cedures

Removing the atomicity restriction from reactive ob jects readily allows for con

current reactive ob jects Concurrency control can be intro duced in the same way

as for passive ob jects Act another extension of C is an example of this

approach Kafura et al Inspired by the actor mo del Act supp orts reac

tive ob jects as instances of sub classes of a given class Actor Synchronization is

achieved byhaving an ob ject switchbetween dierent behaviours each tiedtoaset

of op erations whose invo cations are acceptable by that behaviour

Even autonomous not just reactive active ob jects are p ossible without a b o dy

In CEiel op erations can b e sp ecied as autonomous using the autonomy annotation

The language thus allows to decide for each op eration of a class whether

it should be synchronous no annotation or asynchronous annotation v or

autonomous annotation An autonomous op eration is executed rep eatedly

without b eing invoked More precisely when an autonomous op eration nishes it is

implicitly invoked anew The scheduling mechanism do es not distinguish between

and implicit invo cations Note that the degree of intraob ject concurrency explicit

is still controlled by the compatibility annotations

The annotations of CEiel blend well with inheritance and avoid anomalies b e

cause any centralization such as represented by a body oracentral synchronization

expression is avoided condition synchronization exclusion synchronization and

autonomyasynchrony are sp ecied per operation and orthogonal ly to each other

Sub classing even with multiple inheritance works just like in the sequential case

no matter if async hronous or autonomous op erations are involved The situation

can b e seen as a generalization of what has b een describ ed as pro cess inheritance

in Thomsen The dierence between a passive and an active class is just that

the former has only synchronous op erations

Figure shows an example with double inheritance Class Alien inherits b oth

from Moving which mo dels ob jects moving autonomously in the plane and from

Beeping which mo dels ob jects rep eatedly pro ducing a sound Thus Alien ob jects

are autonomous and will both move and b eep Their behavior may of course be

inuenced by any additional op erations provided in Alien

CLASS Moving CREATION init

FEATURE interface

position Vector

setVelocityv Vector IS

DO velocitysetvxvy END

FEATURE hidden

velocity Vector

stepTime Real

step IS

DO positionsetpositionx velocityxstepTime

positiony velocityystepTime END

initstartingPoint Vector timeUnit Real IS

DO position startingPoint

stepTime timeUnit END

END Moving

CLASS Beeping CREATION init

FEATURE onb Boolean IS

DO beepon b END

FEATURE

beepon Boolean

sound Speaker

beep IS

DO IF beepon THEN soundbeep END END

inits Speaker IS

DO sound s END

END Beeping

CLASS Alien INHERIT Moving RENAME init AS minit END

Beeping RENAME init AS binit END

CREATION init

FEATURE

END Alien

Figure Multiple inheritance with multithreaded active classes in CEiel

Distribution

An ob ject represen ts an indep endent unit of execution encapsulating data pro ce

dures and p ossibly private resources activity for pro cessing the requests Therefore

a natural option is to consider an ob ject as the unit of distribution and p ossible

replication Furthermore selfcontainedness of ob jects data plus pro cedures plus

p ossible internal activity eases the issue of moving and migrating them around

Also note that message passing not only ensures the separation between services

oered by an ob ject and its internal representation but also provides the indep en

dence of its physical lo cation Thus message passing may subsume both lo cal and

remote invo cation whether sender and receiver are on the same or on distinct pro

cessors is transparent to the programmer as well as p ossible inaccessibility of an

ob jectservice

Distributed implementations are available for many concurrent ob jectoriented

languages Some have even b een designed with distribution in mind right from the

b eginning eg Pool Eiel Charm Distribution transparency sometimes

suers from this approach Ideally the issues of concurrent semantics on the one

hand and distributed implementation on the other hand should b e kept indep endent

of each other This would imply access transparency for all kinds of ob jects active

or passive whether lo cal or remote

Accessibility and fault tolerance

In order to handle inaccessibility of ob jects in the Argus distributed op erating

system LiskovSheier the programmer ma y asso ciate an exception with an

invo cation If an ob ject is lo cated on a pro cessor which is inaccessible b ecause of

a network or pro cessor fault an exception is raised eg to invoke another ob ject

A transaction is implicitly asso ciated to eachinvo cation synchronous invo cation in

Argus to ensure atomicity prop erties For instance if the invo cation fails eg if

the server ob ject b ecomes unaccessible the eects of the invocation are canceled

The Karos distributed programming language Guerraoui et al extends the

Argus approach by allowing the asso ciation of transactions also to asynchronous

invo cations

Migration

In order to improve the accessibility of ob jects some languages or systems supp ort

mechanisms for ob ject migration Ob ject migration has b een pioneered by Emerald

Jul et al A more recent and truly ob jectoriented system is Dow l Achauer

a distributed extension of the TrellisOwl language MossKohler Dowl fea

tures a standard attribute location of typ e Node for each ob ject This attribute

can be read and written changing its value causes the ob ject to migrate to a new

no de This can even happ en on the y ie while an op eration is in execution

If any attribute a of a class C is declared a attached T with some typ e T this

implies colocation of any C ob ject c and the ob ject referred to by ca Attachment

is transitive but not symmetric

Parameter migration towards an invoked ob ject can b e sp ecied as either p erma

nent callbymove or temp orary callbyvisit All these features have been

adapted from similar features of Emerald

Explicit migration control is of course not distributiontransparent It can also

be argued that the programmer may not have sucient knowledge to use those

language features in an ecient way Implicit migration control combined with

may be an alternative see b elow clever heuristics

Replication

As for migration a rst motivation of replication is in increasing the accessibility

of an ob ject by replicating it onto the pro cessors of its remote clients A second

motivation is faulttolerance By replicating an ob ject on several pro cessors its ser

vices b ecome robust against p ossible pro cessor failure In b oth cases a fundamental

issue is to maintain the consistency of the replicas ie to ensure that all replicas

hold the same values In the Electra Maeis distributed system the concept of

remote invo cation has b een extended in the following fashion invoking an ob ject

leads to the invo cation of all its replicas while ensuring that concurrent invo cations

are ordered along the same total order for all replicas A system supp orting weaker

orderings exploiting knowledge ab out the semantics of the op erations is describ ed

in Huang A general mechanism for group invocation that is wellsuited for

replicated ob jects was intro duced in BlackImmel

Parallelism

If the concurrent activities of a program are to run in a truly parallel fashion the

program has to be mapp ed to a multipro cessor a multicomputer or a computer

network giving rise to what is known as functional or task paral lelism For mas

sive parallelism however there is more potential in data paral lelism of the SPMD

typ e single program multiple data which is wellsuited for distributedmemory

architectures

We have already seen EPEE an SPMD library for Eiel Charm also

of the integrative approach We have not men mentioned ab ove is an example

tioned Charms sp ecic abilities for SPMD yet There exists a variant of the chare

class concept called the branchedchare class instances of which are called branched

chares A branched chare is a distributed ob ject its co de is replicated among the

no des of a distributedmemory computer or of a computer network and eachnode

works on one fragmentofthe ob ject

Similar as they may seem there is a big dierence b etween the ob ject mo dels of

EPEE and Charm the interface of a branched chare class reects the fragmen

tation in that it describ es the messages or dually the asynchronous invo cations it

can accept from other fragments in addition to messages from other ob jects chares

or branched chares Th us although EPEE has the advantage of hiding the explicit

op erations for interfragment message passing from the clients of an ob ject pro

gramming in Charm is less cumb ersome because message passing is built into

the language as chare invo cation

The ubiquity of C has given rise to a variety of approaches to parallel pro

gramming based on that language WilsonLu most of them integrative The

ma jority tries to avoid explicit message passing so that the ob ject mo del is not

blurred by a dierent and lowerlevel paradigm

Limitations of the integrative approach

The integrative approach attempts at unifying ob ject mechanisms with parallelism

and distribution mechanisms Meanwhile some conicts may arise between them

as we will see b elow

Inheritance anomaly

Inheritance is one of the key mechanisms for achieving reuse of ob jectoriented

programs It is therefore natural to use inheritance to sp ecialize synchronization

sp ecications asso ciated with a class of ob jects Unfortunately as we have seen in

several examples synchronization is dicult to sp ecify and even more dicult to

reuse b ecause of the high interdep endency between the synchronization conditions

for dierent metho ds various uses of inheritance inheriting variables metho ds

synchronizations may conict with each other as noted in McHale Baquero

et al In some cases dening a new sub class even only with one additional

metho d may force the redenition of all synchronization sp ecications

Sp ecications along centralized schemes turn out to be very dicult to reuse

and often must be completely redened Decentralized schemes being mo dular by

essence are b etter suited for selective sp ecialization However this negrained de

comp osition down to the level of each metho d may also fail to solve the problem

This is b ecause synchronization sp ecications even if decomp osed for each metho d

may still remain interdep endent wehave seen in that for intraob ject synchro

nization with synchronization counters adding a delete metho d in a sub class forces

the redenition of the remove guard See MatsuokaYonezawa for a detailed

analysis and classication of the p ossible problems

Recent directions prop osed for minimizing the problem include the following

sp ecifying and sp ecializing indep endently condition and exclusion synchroniza

tion Thomas and autonomyasynchrony Lohr shunning synchroniza

tion counters allowing the programmer to select among several schemes Mat

suokaYonezawa and generic synchronization p olicies as an alternative

to inheritance for reusing synchronization sp ecications McHale

Compatibility of transaction proto cols

It is tempting to integrate transaction proto cols for concurrency control into ob

jects Thus one may lo cally dene for a given ob ject the optimal concurrency

control or recovery proto col For instance commutativity of op erations enables the

interleaving without blo cking of transactions on a given ob ject Unfortunately the

gain in mo dularity and sp ecialization may lead to incompatibility problems Weihl

Broadly sp eaking if ob jects use dierent transaction serialization proto cols ie

serialize the transactions along dierent orders global executions of transactions

may b ecome inconsistent ie non serializable A prop osed approach to handle this

problem is dening lo cal conditions to be veried by ob jects in order to ensure

their compatibilityWeihl Guerraoui

Replication of ob jects and communications

The communication proto cols whichhave b een designed for faulttolerant distributed

computing see Sect consider a standard clientserver mo del The straight

forward transfer of such proto cols to the ob ject mo del leads to the problem of

unexp ected duplication of invo cations An ob ject often acts b oth as a client and as

a server Thus an ob ject which has been replicated as a server may in turn invoke

other ob jects as a client As a result all replicas of the ob ject will invoke these

other ob jects several times This unexp ected duplication of invo cations may lead

in the b est case to ineciencyintheworst case to inconsistencies A solution pro

p osed in Mazouni et al is based on preltering and postltering Preltering

consists of co ordinating pro cessing by the replicas when considered as a client in

order to generate a single invo cation Postltering is the dual op eration for the

replicas when considered as a server in order to discard redundant invo cations

Factorization vs distribution

Last a more general limitation ie less sp ecic to the integrative approach

comes from standard implementation frameworks for ob ject factorization mecha

nisms which usually rely on strong assumptions ab out centralized single memory

architectures

The concept of class variables supp orted by several ob jectoriented program

ming languages is dicult and exp ensive to implement for a distributed system

Unless intro ducing complex and costly transaction mechanisms consistency is hard

to maintain once instances of a same class are distributed among pro cessors Note

that this is a general problem for any kind of shared variable Standard ob ject

oriented metho dology tends to forbid the use of shared variables but may advo cate

using class variables instead

In a related problem implementing inheritance on a distributed system Wol

leads to the problem of accessing remote co de for sup erclasses unless all class

co de is replicated to all pro cessors which has obvious scalability limitations A

semiautomatic approach consists of grouping classes into autonomous mo dules so

as to help with partitioning the class co de among pro cessors

A rather dierent approach replaces the inheritance mechanism b etween classes

with the conceptmechanism of delegation between ob jects This mechanism has ac

tually b een intro duced in the actor concurrent programming language Act Lieb er

man Intuitively an ob ject which do es not understand a message will then del



egate it ie forward it to another ob ject called its pr oxy The proxy will pro cess

the message in place of the initial receiver or it can also itself delegate it further

to its own designated proxy This alternative to inheritance is very app ealing as it

only relies on message passing thus it blends well with distributed implementation

Note however that the delegation mechanism needs some nontrivial synchroniza

tion mechanism to ensure the prop er handling ordering of recursive messages

prior to other incoming messages Thus it may not oer a general and complete

alternative solution BriotYonezawa

Evaluation of the integrative approac h

In summarytheintegrative approach is app ealing b ecause it merges concepts from

ob jectoriented and distributed programming It thus presents a minimal number

of concepts and a single conceptual framework to the programmer Nevertheless



Note that in order to handle recursion prop erly the delegated message will include the initial

receiver

as we discussed in Sect this approach unfortunately suers from limitations in

some asp ects of the integration

Another p otential weakness is that a to o systematic unicationintegration may

lead to a to o restrictive mo del to o much uniformity kills variety and to inef

ciencies For instance stating that every ob ject is active or that every message

transmission is a transaction may be inappropriate for some applications not nec

essarily requiring such proto cols and their asso ciated computational load Last but

not least wemayhavealegacy problem diculties with reusing standard sequential

programs Encapsulation of sequential programs into active ob jects may lo ok likea

straightforward solution But note that cohabitation of active and passive ob jects

may require the observance of certain metho dological rules Caromel

The Reective approach

As we discussed earlier the library approach helps with structuring concurrent pro

gramming concepts and mechanisms due to encapsulation genericity class and

inheritance concepts The integrative approach minimizes the amount of concepts

to be mastered by the programmer and makes mechanisms more transparent but

at the cost of p ossibly reducing the exibilityand the eciency of the mechanisms

oered Indeed programming systems built from libraries are often more extensible

than languages designed along the integrative approach Libraries help at structur

ing and simulating various solutions and thus usually bring go o d exibility whereas

brand new languages may freeze their computation and communication mo dels to o

early In other words it would be interesting to keep the unication and simpli

cation advantages of the integrative approach while retaining the exibility of the

applicativelibrary approach

One imp ortant observation is that the library approach and the integrative ap

proach actually address dierent levels of concerns and use the integrated approach

is for the application programmer and the library approach is for the system pro

grammer In other words the end user programs his or her applications with an

integrative simple and unied approachinmind The system programmer or the

more exp ert user builds or customizes the system through the design of libraries

of proto col comp onents following the library approach

Therefore and as opp osed to what one may think at rst the library approach

and the integrative approacharenot in comp etition but rather complementary The

issue is then How can we actually combine these two levels of programming

and to be more precise How do we interface them It turns out that a general

metho dology for adapting the behavior of computing systems named reection

oers such kind of a glue

Reection

Reection is a general metho dology to describ e control and adapt the b ehaviour of

a computational system The basic idea is to provide a representation of the imp or

tantcharacteristicsparameters of the system in terms of the system itself In other

words static representation characteristics as well as dynamic execution charac

teristics of application programs are made concrete into one or more programs

which represents the default computational behaviour interpreter compiler exe

cution monitor Such a descriptioncontrol program is called a metaprogram

Sp ecializing such programs allows for customizing the execution of the application

program by p ossibly changing data representation execution strategies mecha

nisms and proto cols Note that the same language is used both for writing ap

plication programs and for metaprograms controlling their execution However

the complete separation between the application program and the corresp onding

metaprograms is strictly enforced

Reection helps at decorrelating libraries sp ecifying implementation and exe

cution mo dels execution strategies concurrency control ob ject distribution from

the application program This increases mo dularity readability and reusability of

programs Last reection provides a metho dology to op en up and make adaptable



through a metainterface implementation decisions and resources management

which are often hardwired and xed or delegated by the programming language to

the underlying op erating system

In summary reection helps at integrating proto col libraries tightly within a

programming language or system thus providing the interfacing framework the

glue b etween the integrative and the library approacheslevels

Reection and ob jects

Reection ts esp ecially well with ob ject concepts which enforce a go o d encapsula

tion of levels and a mo dularity of eects It is therefore natural to organize the con

trol of the b ehaviour of an ob jectoriented computational system its metainterface

through a set of ob jects This organization is named a MetaObject Protocol MOP

Kiczales et al and its comp onents are called metaobjects Maes as meta

programs are represented by ob jects They may represent various characteristics

of the execution context such as representation implementation execution com

munication and lo cation By sp ecializing metaob jects we may extend and mo dify

lo callythe execution context of some sp ecic ob jects of the application program

Reection may also help with expressing and controlling resources management

not only at the level of an individual ob ject but also at a broader level suchassched

uler pro cessor name space ob ject group such resources also b eing represented

by metaob jects This allows for a very negrained control eg for scheduling and

load balancing with the whole expressive power of a full programming language

OkamuraIshikawa as opp osed to some global and xed algorithm which is

usually optimized for a sp ecic kind of application or an average case



This metainterface enables the client programmer to adapt and tune the behaviour of a soft

ware mo dule indep endently of its functionalities which are accessed through the standard base

interface This has b een named the concept of open implementation Kiczales

Examples of metaob ject proto cols MOPs

The Co dA architecture McAer is a representative example of a general ob ject



based reective architecture ie a MOP based on metacomponents Co dA

considers by default seven metacomp onents asso ciated to each ob ject corre

sp onding to message sending receiving buering selection method lookup exe

cution and state accessing An ob ject with default metacomp onents b ehaves like



a standard sequential and passive ob ject Attaching sp ecic sp ecialized meta

comp onents allows to selectively changing a sp ecic asp ect of the representation or

execution mo del for a single ob ject A standard interface b etween metacomp onents

supp orts comp osing metacomp onents from dierent origins

Note that some other reective architectures may be more sp ecialized and may

oer a more reduced and abstract set of metacomp onents Examples are the

Actalk and GARF platforms where a smaller amount of metacomp onents may be

in practice sucient to express a large varietyofschemes and application problems

The Actalk platform Briot Briot helps at exp erimenting with various syn

chronization and communication mo dels for a given program bychanging and sp e

cializing various mo delscomp onents of activity implicit or explicit acceptance

of requests intraob jet concurrency etc and synchronization abstract b ehaviours

guards etc communic ation synchronous asynchronous etc and invoca

tion time stamp priority etc The GARF platform Garbinato et al for

distributed and faulttolerant programming oers a variety of mechanisms along

two dimensionscomp onents ob ject control p ersistence replication etc and

communication multicast atomic etc

More generally sp eaking dep ending on the actual goals and the balance exp ected

between exibility generality simplicity and eciency design decisions will dictate

the amount and the scop e of the mechanisms which will be op enedup to the

metalevel Therefore some mechanisms may be represented as reective methods

while b elonging to standard ob ject classes that is without explicit and complete

metaob jects

Smalltalk is a representative example of that latter category In addition to

the metarepresentation of the program structures and mechanisms as rst class

ob jects see Sect a few very powerful reective mechanisms oer some con

trol over program execution Examples are redenition of error handling message

reference to current context references swap changing the class of an ob ject etc

Such mechanisms facilitate building and integrating various platforms for concur

ren t parallel and distributed programming such as Simtalk Actalk GARF and

Co dA itself



Note that metacomp onents are indeed metaob jects In the following we will rather use the

term metacomponent in order to emphasize the pluggability asp ects of a reective architecture

MOP such as Co dA Also for simplication we will often use the term component in place of

metacomponent



To be more precise as a standard Smalltalk ob ject as Co dA is currently implemented in

Smalltalk

Examples of applications

To illustrate how reection may enable us to map various computation mo dels and

proto cols onto user programs we will quickly survey some examples of exp eriments

with a sp ecic reectivearchitecture Wechose Co dA See McAer for a more

detailed description of its architecture and libraries of comp onents

Note that in the case of the Co dA system as well as for almost all other examples

of reective systems further describ ed the basic programming mo del is integrative

while reection enables the customization of parallelism and distribution asp ects

and proto cols by sp ecializing libraries of metacomp onents

Concurrency mo dels

In order to intro duce concurrency for a given ob ject by making it into an active

ob ject following the integrated approach two metacomp onents are sp ecialized

The sp ecialized message buering comp onent is a queue which will buer incoming

messages The sp ecialized execution comp onent asso ciates an indep endent activity

thread with the ob ject This thread executes an innite lo op that accepts messages

from the buering comp onent

Distribution mo dels

In order to intro duce distribution a new metacomp onent is added for marshaling

messages In addition two new sp ecic ob jects are intro duced which represent the

notion of a remote reference to a remote ob ject and the notion of a memoryname

space The remote reference ob ject has a sp ecialized message receiving comp onent

which marshals the message into a stream of bytes and sends it through the network

to the actual remote ob ject This ob ject has another sp ecialized message receiving

comp onent which reconstructs and actually receives the message Marshaling deci

sions eg which argument should b e passed by reference byvalue ie acopy up

to which level etc may be sp ecialized by a marshaling descriptor supplied to the

marshaling comp onent

Migration and replication mo dels

Migration is intro duced by a new metacomp onent which describ es the form and

the p olicies ie when it should o ccur for migration Replication is managed by

adding two new dual metacomp onents The rst one is in charge of controlling

the state of the original ob ject The second one controls the access to access to

each of its replicas Again marshaling decisions such as which argument should

be passed by reference by value by move ie migrated as in Emerald with

attachments etc may b e sp ecialized through the marshaling descriptors supplied by

the corresp onding comp onent Also one may sp ecialize asp ects such as which parts

of the ob ject should be replicated and various management p olicies for enforcing

the consistency between the original ob ject and its replicas

The default buering comp onent is actually directly passing incoming messages on to the

execution comp onent

Other Examples of reective architectures

We will briey mention other related examples of representative reective architec

tures and their applications not trying to b e exhaustive

Dynamic installation and comp osition of proto cols

The general MAUD metho dology Agha et al fo cuses on fault tolerance proto

cols suchasserver replication checkp oint etc Its sp ecicity lies in oering a frame

work for dynamic instal lation and composition of sp ecialized metacomp onents The

dynamic installation of metacomp onents allows the installation of a given proto col

only when needed and without stopping the program execution The p ossibilityto

asso ciate metacomp onents not only to ob jects but also to other metacomp onents

which are rstclass ob jects enables the layered comp osition of proto cols

Control of migration

reinforced in the case of The autonomy and selfcontainedness of ob jects further

active ob jects makes them easier to migrate as a single piece Nevertheless the

decision to migrate an ob ject is an imp ortant issue which often remains with the

programmer As mentioned in it maybe interesting to semiautomate such a

decision along various considerations such as pro cessor load ratio of remote com

munications etc Reection helps with integrating such statistical data residing for

physical and shared resources and with using them byvarious migration algorithms

describ ed at the metalevel OkamuraIshikawa

Customizing system p olicies

The Ap ertos distributed op erating system Yokote represents a signicant and

innovativ e example of a distributed op erating system completely designed with an

ob jectbased reective architecture MOP In addition to the mo dularity and the

genericity of the architecture of systems like Choices or Peace reection op ens up

another dimension of p ossibly dynamic customization of the system towards ap

plication requirements For example we can easily sp ecialize the scheduling p olicy

in order to supp ort various kinds of schedulers eg a realtime scheduler An

other gain is in the size of the microkernel obtained which is particularly small

as it is reduced to supp orting the basic reective op erations and the basic resources

This facilitates b oth the understanding and the p orting of the system abstractions

Reective extension of an existing commercial system

A reective metho dology has recently b een used in order to incorp orate extended

transaction mo dels into an existing commercial transaction pro cessing system It

extends a standard transaction pro cessing monitor in a minimal and disciplined

way based on up calls to intro duce features suchaslock delegation dep endency

tracking between transactions and denition of conicts and to represent them

That is relaxing some of the standard ACID transaction prop erties

as reective op erations BargaPu These reective primitives are then used

to implement various extended transaction mo dels such as splitjoin co op erative

groups etc

Related techniques for customizing behavior

We nally mention two examples of customizing computational behavior that are

closely related to reection

The comp ositionlters mo del

The SINA language is based on the notion of a lter a way to sp ecify arbitrary

manipulation and actions for messages sent to or from an ob ject Aksit et al

t some reication of the communication and a In other words lters represen

interpretation mechanism b etween ob jects By combining various lters for a given

ob ject one may construct complex interaction mechanisms in a comp osable way

Generic runtime as a dual approach

The b oundary between programming languages and op erating systems is getting

thinner Reective programming languages have some highlevel representation of

the underlying execution mo del Conversely and dual to reection several dis

tributed op erating systems provide a generic run time layer as for instance the

COOL layer for the Chorus op erating system Lea et al These generic run

time layers are designed to be used by various programming languages up calls

are used to delegate sp ecic representation decisions to the programming language

Evaluation of the reective approach

Reection provides a general framework for the customization of parallelism and

distribution asp ects and proto cols by sp ecializing and integrating metalibraries

intimately within a language or system while separating them from the application

program

Many reective architectures are currently prop osed and evaluated It is to o

early to nd and validate a general and optimal reective architecture for parallel

and distributed programming although we believe that Co dA is a promising step

in that direction Meanwhile we need more exp erience in the practical use of

reection to be able to nd go o d tradeos between the exibility required the

architecture complexity and the resulting eciency One p ossible and currently

justied complaint is ab out the actual relative complexity of reective architectures

Nevertheless and indep endently of the required cultural change we b elievethatthis

is the price that has to be paid for the increased alb eit disciplined exibility that

they oer Another signicant current limitation concerns eciency a consequence

of extra indirections and interpretations Partial evaluation also called program

sp ecialization is currently prop osed as a promising technique to minimize such

overheads Masuhara et al

Conclusion

Towards a b etter understanding and evaluation of various ob jectbased parallel and

distributed developments we have prop osed a classication of the dierent ways

in which the ob ject paradigm is used in concurrent environments We have identi

ed three dierent approaches which convey dierent yet complementary research

streams in the ob jectoriented concurrent systems community

The library approach helps with structuring concurrent programming concepts

and mechanisms through encapsulation genericity classes and inheritance Its prin

cipal limitation is that the solution of an application problem is represented by

unrelated sets of concepts and ob jects The library approach can be viewed as a

b ottomup approach and is directed towards system builders

The integrative approach minimizes the amount of concepts to be mastered by

the programmer and makes mechanisms more transparent by providing a unied

concurrent highlevel ob ject mo del However this is at the cost of p ossibly reducing

the exibility and eciency of the mechanisms The integrative approach can be

viewed as a topdown approach and is directed towards application builders

Finally by providing a framework for integrating proto col libraries within a

programming language or system the reective approach provides the interfacing

framework the glue b etween the library and the integrative approaches It also

enforces the separation of their resp ectivelevels In other words reection provides

the metainterface through which the system designer may install system customiza

tions and thus change the execution context parallel distributed faulttolerant

realtime adaptivewithminimalchanges in the application programs

The reective approach also contributes to blurring the distinction b etween pro

gramming language op erating system and data base and at easing the development

dynamically adaptation and optimization of a minimal computing system which is

extensible Nevertheless we should always keep in mind that this do es not free us

from the necessity of a good basic design and a sound set of fundamental abstrac

tions

References

Achauer Achauer B The Dowl distributed ob jectoriented language

Comm ACM

Ada Ada The Programming Language Ada Reference Manual LNCS

SpringerVerlag

Ada Ada Ada Rationale Intermetrics Inc Cambridge Mass

Agha Agha G Actors A Model of Concurrent Computation in Dis

tributed Systems Series in Articial Intelligence MIT Press

Agha et al Agha GA Wegner P Yonezawa A Eds Proc

ACM Sigplan Workshop on ObjectBased Concurrent Programming ACM

Sigplan Not

Agha et al Agha GA Hewitt C Wegner P Yonezawa A Eds

Proc OOPSLAECOOP Workshop on ObjectBased Concurrent

Programming ACM OOPS Messenger

Agha et al a Agha GA Wegner P Yonezawa A Eds Re

search Directions in Concurrent ObjectOrientedProgramming MIT Press

Agha et al b Agha GA Frlund S Panwar R Sturman D

A linguistic framework for dynamic comp osition of dep endabilitypro

to cols Dependable Computing for Critical Applications III DCCAIFIP

Transactions Elsevier

Aksit et al a Aksit M Wakita K Bosch J Bergmans L

Yonezawa A Abstracting ob ject interactions using comp osition

lters In Guerraoui et al

Aksit et al b Aksit M Bosch J van der Sterren W Bergmans

L Realtime sp ecication inheritance anomalies and realtime l

ters Proc European Conf on ObjectOrientedProgramming ECOOP

LNCS SpringerVerlag

America America PHM PoolT a parallel ob jectoriented lan

guage In YonezawaTokoro

America America PHM Denition of Po ol a parallel ob ject

oriented language ESPRIT pro ject A rep ort Philips Research Lab

oratories

America America PHM Issues in the design of a parallel ob ject

oriented language Formal Aspects of Computing

Americavan der Linden America PHM van der Linden F

A parallel ob jectoriented language with inheritance and subtyping Proc

OOPSLAECOOP ACM Sigplan Not

Andersen Andersen B A general negrained machine

indep endent ob jectoriented language ACM Sigplan Not

Andler Andler S Predicate Path Expressions Proc ACM Symp

amming Languages on Principles of Progr

AndrewsMcGraw Andrews GR McGraw JR Language fea

tures for pro cess interaction Proc ACM Conf on Language Design for Re

liable Software ACM Sigplan Not

Andrews Andrews GR Concurrent Programming Principles and

Practice BenjaminCummings

AndrewsOlsson Andrews GR Olsson RA The SR Program

ming Language BenjaminCummings

ArnoldGosling Arnold K Gosling J The Java Programming

Language AddisonWesley

Atkinson Atkinson C ObjectOrientedReuse Concurrency and Dis

tribution AddisonWesley

Atkinson et al Atkinson C Goldsack SJ Di Maio A Bayan

R Ob jectoriented concurrency and distribution in Drago on J of

ObjectOriented Programming MarchApril

Bahsoun et al Bahsoun JP Feraud L Betourne C The

two degrees of freedom approach for parallel programming Proc Int

Conf on Computer Languages IEEE

Bal et al Bal HE Kaashoek MF Tanenbaum AS Orca a

language for parallel programming of distributed systems IEEE T rans on

Software Engineering

Balter et al Balter R Lacourte S Riveill M The Guide

language The Computer Journal

Baquero et al Baquero C Oliveira R Moura F Integra

tion of concurrency control in a language with subtyping and sub classing

USENIX COOTS Conference COOTS Monterey CA

BargaPu Barga R Pu C A practical and mo dular implementa

tion of extended transaction mo dels Technical Rep ort CSE Oregon

Graduate Institute of Science Technology Portland OR

Barnes Barnes J Ada Rationale The Language The Standard

Libraries SpringerVerlag

Bergmans Bergmans L Composing Concurrent Objects PhD thesis

Universiteit Twente

Bernstein et al Bernstein P Hadzilacos V Goodman N

Concurrency Control and Recovery in Database Systems AddisonWesley

Bershad et al Bershad BN Lazowska ED Levy HM

PRESTO a system for ob jectoriented parallel programming Software

Practice and Experience

Bezivin Bezivin J Some Exp eriments in Ob jectOriented Simulation

ACM Conf on ObjectOriented Programming Systems Languages and Ap

plications OOPSLA

Birtwistle et al Birtwistle GM Dahl OJ Myhrhaug B Ny

gaard K Simula BeginPetro celli Charter

Black et al Black AP Hutchinson N Jul E Levy H Carter

L Distribution and abstract typ es in Emerald IEEE Trans on Soft

ware Engineering

Black Black AP Understanding transactions in the op erating sys

tem context Operating Systems Review

BlackImmel Black AP Immel MP Encapsulating Plurality

Proc European Conf on ObjectOrientedProgramming ECOOP LNCS

SpringerVerlag

Boles Boles D Parallel ob jectoriented programming with QPC

Structured Programming

van den BosLara van den Bos J Laffra C Pro col a con

current ob jectoriented language with proto cols delegation and constraints

Acta Informatica

BrandtLehrmann Madsen Brandt S Lehrmann Madsen O

Ob jectOriented Distributed Programming in BETA In Guerraoui et al

BriotYonezawa Briot JP Yonezawa A Inheritance and syn

chronization in concurrent OOP Proc European Conf on ObjectOriented

LNCS SpringerVerlag Programming ECOOP

Briot Briot JP Actalk a testb ed for classifying and designing actor

languages in the Smalltalk environment Proc European Conf on Object

OrientedProgramming ECOOP Cambridge University Press

Briot et al Briot JP Geib JM Yonezawa A Eds Proc

FranceJapan Workshop on ObjectBasedParal lel and Distributed Computa

tion LNCS SpringerVerlag

Briot Briot JP An exp eriment in classication and sp ecialization

of synchronization schemes Proc Int Symp on Object Technologies for

Advanced Software ISOTAS LNCS SpringerVerlag

Bruin et al de Bruin H Bouwman P van den Bos J Taming

concurrency in Smalltalk the Pro col approach ObjectOriented Systems

Buhr et al Buhr PA Ditchfield G Stroobosscher RA

Younger BM C concurrency in the ob jectoriented lan

guage C Software Practice and Experience

Campb ellHab ermann Campbell RH Habermann AN The

sp ecication of pro cess synchronization by path expressions In Gelenbe

E Kaiser C Eds Operating Systems LNCS SpringerVerlag

Campb ell et al Campbell R Islam N Raila D Madany P

Designing and implementing Choices an ob jectorien ted system in C

Comm ACM

Cap obianchi et al Capobianchi R Guerraoui R Lanusse A

Roux P Lessons from implementing active ob jects on a parallel

machine Usenix Symp on Experiences with Distributed and Multiprocessor

Systems

Caromel Caromel D Service asynchrony and waitbynecessity J

of ObjectOriented Programming

Caromel Caromel D Concurrency and reusability from sequential

to parallel J of ObjectOriented Programming

Caromel Caromel D Towards a metho d of ob jectoriented concur

rent programming Comm ACM

Chandra et al Chandra R Gupta A Hennessy JL COOL

an ob jectbased language for parallel programming IEEE Computer

ChandyKesselman Chandy KM Kesselman C CC a

declarative concurrent ob jectoriented programming notation In Agha et

al

Chien a Chien AA Concurrent Aggregates MIT Press

Chien b Chien AA Supp orting mo dularity in highlyparallel pro

grams In Agha et al

Ciancarini et al Ciancarini P Nierstrasz O Yonezawa A Eds

ObjectBasedModels and L anguages for Concurrent Systems ECOOP

Workshop LNCS SpringerVerlag

ColinGeib Colin JF Geib JM Eiel classes for concurrent

programming Proc TOOLS PrenticeHall

CorradiLeonardi Corradi A Leonardi L PO constraints as

toolstosynchronize active ob jects J of ObjectOrientedProgramming

Decouchant et al Decouchant D Le Dot P Riveill M Roisin C

Rousset de Pina X A synchronization mechanism for an ob ject

oriented distributed system Proc Int Conf on DistributedProgramming

Systems IEEE

Feldman et al Feldman JA Lim CC Rauber Th The

sharedmemory language pSather on a distributedmemory multipro cessor

Proc Workshop on Languages Compilers and Runtime Envir onments for

DistributedMemory Multiprocessors ACM Sigplan Not

Finkeet al Finke S Jahn P Langmack O Lohr KP Piens I

Wolff Th Distribution and inheritance in the HERON approach

to heterogeneous computing Proc Int Conf on Distributed Computing

Systems IEEE

Frlund Frlund S Inheritance of synchronization constraints in con

current ob jectoriented programming languages Proc European Conf on

ObjectOriented Programming ECOOP LNCS SpringerVerlag

Frlund Frlund S Coordinating Distributed Objects MIT Press

Garbinato et al Garbinato B Guerraoui R Mazouni KR

Distributed programming in GARF In Guerraoui et al

GehaniRo ome Gehani NH Roome WD Concurrent C

concurrent programming with classes Software Practice Experience

Goldb ergRobson Goldberg A Robson D Smal ltalk The

Language AddisonWesley

Grimshaw et al Grimshaw AS Strayer W Narayan P Dy

namic ob jectoriented parallel pro cessing IEEE Paral lel and Distributed

Technolo gy

Guerraoui et al Guerraoui R Capobianchi R Lanusse A Roux

P Nesting actions through asynchronous message passing the

ACS proto col Proc European Conf on ObjectOriented Programming

ECOOP LNCS SpringerVerlag

Guerraoui et al Guerraoui R Nierstrasz O Riveill M Eds

Proc ECOOP Workshop on ObjectBased Distributed Program

ming LNCS SpringerVerlag

GuerraouiSchip er Guerraoui R Schiper A The transaction

Birman K Cris mo del vs virtual synchrony mo del bridging the gap In

tian F Mattern F Schip er A Eds Distributed Systems From Theory

to Practice LNCS SpringerVerlag

Guerraoui Guerraoui R Mo dular atomic ob jects Theory and Prac

tice of Object Systems

GunaseelanLeBlanc Gunaseelan L LeBlanc RJ Distributed

Eiel a language for programming multigranular distributed ob jects Proc

Int Conf on Computer Languages IEEE

Halstead Halstead RH Multilisp a language for concurrent sym

b olic computation ACM Trans on Programming Languages and Systems

Hamelin et al Hamelin F Jezequel JM Priol T A multi

paradigm ob jectoriented parallel environment Proc Int Paral lel Pro

cessing Symposium Cancun

Harbison Harbison SP Modula PrenticeHall

Holmes et al Holmes D Noble J Potter J Asp ects of syn

chronization Proc TOOLS Pacic IEEE

Huang Huang S Developing distributed applications by semantics

based automatic replication Proc AsiaPacic Software Engineering

Conf Tokyo

al Ishikawa Y Tokuda H Mercer CW An Ishikawa et

ob jectoriented realtime programming language IEEE Computer

Issarny Issarny V An exception handling mechanism for parallel

ob jectoriented programming J of ObjectOriented Programming

Jezequel a Jezequel JM EPEE an Eiel environment to program

distributedmemory parallel computers J of ObjectOriented Programming

Jezequel b Jezequel JM Transparent parallelization through reuse

between a compiler and a library approach Proc European Conf on Object

Oriented Programming ECOOPLNCS SpringerVerlag

Jez equel et al Jezequel JM Guidec F Hamelin F Paral

lelizing ob jectoriented software through the reuse of parallel comp onents

ObjectOriented Systems

Jul et al Jul E Levy HM Hutchinson NC Black AP

Finegrained mobility in the Emerald system ACM Trans on Computer

Systems

KafuraLee Kafura DG Lee KH Act building a concurrent

C with actors J of ObjectOriented Programming

Kafura et al Kafura D Mukherji M Lavender G Act

C using actors J of A class library for concurrent programming in

ObjectOriented Programming October

KaleKrishnan Kale LV Krishnan S Charm a p ortable con

current ob jectoriented system based on C Proc ACM Conf on Object

Oriented Systems Languages and Applications OOPSLA ACM Sig

plan Not

KaraormanBruno Karaorman M Bruno J Intro ducing concur

rency to a sequential language Comm ACM

Kiczales et al Kiczales G des Rivieres J Bobrow D The

Art of the MetaObject Protocol MIT Press

Kiczales Kiczales G Ed Foil for the Workshop On Op en Imple

mentation httpwwwparcxeroxcom PAR Cs ple cao i

workshopfoilmainht ml

LauerNeedham Lauer HC Needham RM On the duality of

op erating system structures Proc Int Symp on Operating Systems IRIA

Rocquencourt Reprinted in ACM Operating Systems Review

Lea et al Lea R Jacquemot C Pillevesse E COOL System

supp ort for distributed programming Comm ACM

Lea Lea D Concurrent Programming in Java AddisonWesley

Lehrmann Madsen et al Lehrmann Madsen O MllerPedersen B

Nygaard K ObjectOrientedProgramming in the BET AProgram

ming Language AddisonWesley

Lieb erman Lieberman H Concurrent ob jectoriented programming

in Act In YonezawaTokoro

LiskovSheier Liskov B Sheifler R Guardians and actions lin

guistic supp ort for robust distributed programs ACM Trans on Program

ming Languages and Systems

Lohr Lohr KP Concurrency annotations and reusability Rep ort

B FB Mathematik Freie Universitat Berlin

Lohr Lohr KP Concurrency Annotations Proc ACM Conf on

ObjectOrientedSystemsLanguages and Applications OOPSLA ACM

Sigplan Not

Lohr Lohr KP Concurrency annotations for reusable software

Comm ACM

Lop esLieb erherr Lopes CV Lieberherr KJ Abstracting

pro cesstofunction relations in concurrent ob jectoriented applications

Proc European Conf on ObjectOrientedProgramming ECOOP LNCS

SpringerVerlag

Maas Maes P Concepts and exp eriments in computational reection

Proc ACM Conf on ObjectOrientedProgramming Systems Languages and

Applications OOPSLA ACM Sigplan Not

Maeis Maffeis S RunTime Support for ObjectOriented Distributed

Programming PhD dissertation Universitat Zuric h

Malony et al Malony A Mohr B Beckman P Gannon D Yang

S Bodin F Performance analysis of pC a p ortable data

c Int parallel programming system for scalable parallel computers Pro

Paral lel Processing Symposium Cancun

Masuhara et al Masuhara H Matsuoka S Asai K Yonezawa A

Compiling away the metalevel in ob jectoriented concurrent reective

languages using partial evaluation Proc ACM Conf on ObjectOriented

Programming Systems Languages and Applications OOPSLA ACM

Sigplan Not

MatsuokaYonezawa Matsuoka S Yonezawa A Analysis of in

heritance anomaly in ob jectoriented concurrent programming languages In

Agha et al

Mazouni et al Mazouni K Garbinato B Guerraoui R

Building reliable clientserver software using actively replicated ob jects

Proc TOOLS Europe PrenticeHall

McAer McAffer J Metalevel programming with Co dA Proc Eu

ropean Conf on ObjectOriented Programming ECOOP LNCS

SpringerVerlag

McHale et al McHale C Walsh B Baker S Donnelly A

Scheduling Predicates In Tokoro et al

McHale McHale C Synchronization in Concurrent ObjectOriented

Languages Expressive Power Genericity and Inheritance PhD thesis

Trinity College Dublin Dept of Computer Science

McHughCahill McHugh C Cahill V Eiel an implemen

tation of Eiel on Amadeus a p ersistent distributed applications supp ort

environment Proc TOOLS Europe PrenticeHall

Meseguer Meseguer J Solving the inheritance anomaly in concur

rent ob jectoriented programming Proc European Conf on ObjectOriented

Programming ECOOP LNCS SpringerVerlag

Meyer Meyer B Eiel The Language PrenticeHall

Meyer Meyer B Systematic concurrent ob jectoriented program

ming Comm ACM

Meyer Meyer B ObjectOriented Software Construction ed

PrenticeHall

MossKohler Moss JEB Kohler WH Concurrency features

for the TrellisOwl language Proc European Conf on ObjectOrientedPro

gramming ECOOP LNCS SpringerVerlag

MowbrayZahavi Mowbray TJ and Zahavi R The Essential

CORBA System Integration Using Distributed Objects John Wiley Sons

and The Ob ject Management Group

Neusius Neusius C Synchronizing actions Proc European Conf on

ObjectOriented Programming ECOOP LNCS SpringerVerlag

Nicol et al Nicol J Wilkes T Manola F Ob jectorientation

in heterogeneous distributed computing systems IEEE Computer

Nierstrasz Nierstrasz OM Active ob jects in Hybrid Proc ACM

Conf on ObjectOriented Programming Systems Languages and Applica

tions OOPSLA ACM Sigplan Not

Nierstrasz a Nierstrasz OM Comp osing active ob jects In Agha et

al

Nierstrasz b Nierstrasz OM Regular typ es for active ob jects Proc

ACM Conf on ObjectOriented Programming Systems Languages and Ap

plications OOPSLA ACM Sigplan Not

amuraIshikawa Okamura H Ishikawa Y Ob ject lo cation con Ok

trol using metalevel programming Proc European Conf on ObjectOriented

Programming ECOOP LNCS SpringerVerlag

OMG OMG The Common Object Request Broker Architecture and

Specication Revision Ob ject Management Group Framingham

Mass

OSF OSF DCE Application Development Guide Revision Op en

Software Foundation Cambridge Mass

Papathomas Papathomas M Concurrency issues in ob jectoriented

programming languages In Tsichritzis DC ed ObjectOriented Develop

ersite de Geneve ment Centre Universitaire dInformatique Univ

Papathomas Papathomas M Concurrency in ob jectoriented pro

gramming languages In Nierstrasz O Tsichritzis D Eds ObjectOriented

Software Composition PrenticeHall

ParringtonShrivastava Parrington GD Shrivastava SK Im

plementing concurrency control in reliable distributed ob jectoriented sys

tems Proc European Conf on ObjectOrientedProgramming ECOOP

LNCS SpringerVerlag

Philippsen a Philippsen M Imp erative concurrent ob jectoriented

languages TR International Computer Science Institute Berkeley

Philippsen b Philippsen M Imp erative concurrent ob jectoriented

International Computer languages an annotated bibliography TR

Science Institute Berkeley

Rob ertVerjus Robert P Verjus JP Toward autonomous de

scriptions of synchronization mo dules Proc IFIP Congress North

Holland

Rosenb erry et al Rosenberry W Kenney D Fisher J Un

derstanding DCE OReilly

Rozier Rozier M Chorus Usenix Int Conf on MicroKernels and

Other Kernel Architectures

SchillMo ck Schill A Mock M DC Distributed ob ject

oriented system supp ort on top of OSF DCE Distributed Systems Engi

neering

Schmidt Schmidt DC An OO encapsulation of lightweightOScon

currency mechanisms in the ACE to olkit TR WUCS Dept of Com

puter Science Washington University St Louis

SchroderPreikschat SchroderPreikschat W The Logical Design

of Paral lel Operating Systems PrenticeHall

Sheer Sheffler ThJ The Amelia Vector Template Library In

WilsonLu

Skjellum et al Skjellum A Lu Z Bangalore PV Doss N

MPI In WilsonLu

up B The C Programming Language Stroustrup Stroustr

AddisonWesley

Sun Sun C Library Reference Manual Section Part No

Nov Sun Microsystems Inc

Thomas Thomas L Extensibility and reuse of ob jectoriented syn

chronization comp onents Proc Int Conf on Paral lel Languages and Envi

ronments PARLE LNCS SpringerVerlag

Thomas Thomas L Inheritance anomaly in true concurrent ob ject

oriented languages a prop osal IEEE TENCON

Thomsen Thomsen KS Inheritance on pro cesses exemplied on dis

tributed termination detection Int J of Paral lel Programming

Tokoro et al Tokoro M Nierstrasz OM Wegner P Eds

Proc ECOOP Workshop on ObjectBased Concurrent Computing LNCS

SpringerVerlag

TomlinsonSingh Tomlinson C Singh V Inheritance and syn

chronization with enabledsets Proc ACM Conf on ObjectOriented Pro

gramming Systems Languages and Applications OOPSLA ACM Sig

plan Not

TripathiAksit Tripathi A Aksit M Communication scheduling

and resource managementinSINA J of ObjectOrientedProgramming

Wegner Wegner P Concepts and paradigms of ob jectoriented pro

gramming ACM OOPS Manager

Weihl Weihl W Lo cal atomicity prop erties mo dular concurrency

control for abstract data typ es ACM Trans on Programming Languages

and Systems

WilsonLu Wilson GV Lu P Eds Paral lel Programming Using

C MIT Press

Wing Wing J Decomp osing and recomp osing transaction concepts

In Guerraoui et al

Wol Wolff Th Transparently distributing ob jects with inheritance

es IEEE Proc Hawaii Int Conf on System Scienc

YokoteTokoro Yokote Y Tokoro M Exp erience and evolution

of Concurrent Smalltalk Proc ACM Conf on ObjectOriented Program

ming Systems Languages and Applications OOPSLA ACM Sigplan

Not

Yokote Yokote Y The Ap ertos reective op erating system the con

cept and its implementation Proc ACM Conf on ObjectOrientedProgram

ming Systems Languages and Applications OOPSLA ACM Sigplan

Not

Yonezawa et al Yonezawa A Briot JP Shibayama E

Ob jectoriented concurrent programming in ABCL Proc ACM Conf on

ObjectOriented Programming Systems Languages and Applications OOP

SLA ACM Sigplan Not

YonezawaTokoro Yonezawa A Tokoro M Eds Object

Oriented Concurrent Programming Computer Systems Series MIT Press

Yonezawa et al Yonezawa A Matsuoka S Yasugi M Taura K

Implementing concurrent ob jectoriented languages on m ulticomput

ers IEEE Paral lel and Distributed Technology May