Language Design Rationale and

parentpitaSoftware and s/w Development

Nov 18, 2013 (3 years and 4 months ago)

261 views

Language Design Rationale and
Semantic Framework for Concurrent
Object-Oriented Programming
La Conception et la Description de la Smantique
des Langages Concurrents  Objets
Michael Papathomas
Genve
1992
Language Design Rationale and
Semantic Framework for Concurrent
Object-Oriented Programming
La Conception et la Description de la Smantique
des Langages Concurrents  Objets
Michael Papathomas
Genve
1992
Michael Papathomas
LÕapplication de lÕapproche de programmation par objets pour des applications concurrentes n-
cessite dÕune part, des langages de programmation intgrant les concepts de la programmation
par objets  ceux de la programmation concurrente et dÕautre part, afin de permettre leur rutili-
sation et volution, une description prcise du comportement des objets concurrents et une no-
tion formelle de comportement compatible.
Nous dveloppons un cadre conceptuel, consistant en une typologie des choix de concep-
tion des langages et un ensemble de critres dÕintgration de la programmation concurrente  la
programmation par objets, nous permettant dÕvaluer les diffrentes combinaisons de choix de
conception. Puis, nous proposons une approche pour la description formelle de la smantique
des langages concurrents  objets qui nous permet de reprsenter les diffrents choix de concep-
tion des langages et dÕobtenir une notion formelle du comportement des objets concurrents.
Language Design Rationale and Semantic Framework for
Concurrent Object-Oriented Programming
La Conception et la Description de la Smantique
des Langages Concurrents  Objets
UNIVERSIT DE GENéVE
Dpartement dÕInformatique
FACULT DES SCIENCES
Professeur C.PELLEGRINI
Language Design Rationale and
Semantic Framework for
Concurrent Object-Oriented Programming
THéSE
Prsente  la Facult des Sciences de lÕUniversit de Genve
pour obtenir le grade de Docteur s Sciences mention Informatique
par
Michael PAPATHOMAS
de
Athnes, Grce
Thse No 2522
Genve 1992
La Facult des Sciences, sur le pravis de Messieurs C. PELLEGRINI, professeur ordinaire et
directeur de thse (Dpartement dÕinformatique), D. TSICHRITZIS, professeur ordinaire et co-
directeur de thse (Facult des Sciences conomiques et sociales - Centre Universitaire dÕInfor-
matique), A. YONEZAWA, professeur (Universit de Tokyo) et O.M. NIERSTRASZ, docteur
(Facult des Sciences conomiques et sociales - Centre Universitaire dÕInformatique), autorise
lÕimpression de la prsente thse, sans exprimer dÕopinion sur les propositions qui y sont non-
ces.
Genve, le 6 janvier 1992
Thse No 2522
Le Doyen, Pierre BURI
©
Michael Papathomas 1992. Tous droits rservs
Remerciements
Il y a un certain nombre de personnes qui ont jou un rle important pour la ralisation de ce
travail et auxquelles jÕaimerais exprimer ma gratitude.
Je remercie le Professeur D. Tsichritzis pour avoir suivi et soutenu ce travail depuis le d-
but ainsi que pour sa confiance. Il mÕa permis non seulement dÕaccomplir cette thse mais aussi
dÕlargir considrablement mes connaissances.
Je remercie le Professeur C. Pellegrini pour avoir accepter la direction de cette thse et
avoir rendu possible a ralisation.
Je remercie le Professeur A. Yonezawa pour mÕavoir fait lÕhonneur de faire partie du jury
ainsi que pour son encouragement.
JÕai plusieurs raisons pour remercier le Docteur O.M. Nierstrasz. JÕaimerais le remercier
plus particulirement pour mÕavoir fait connatre le calcul des processus, pour avoir lu et com-
ment plusieurs versions antrieures de cette thse et pour avoir t toujours prt  sÕengager
dans des discussions stimulantes.
Je remercie L. Dami et J. Vitek pour leur encouragement qui a t inestimable ainsi que
pour leurs commentaires et suggestions qui mÕont permis dÕamliorer considrablement la pr-
sentation de mon travail.
Enfin, jÕaimerais remercier mes parents, amis et collgues pour avoir t patients et com-
prhensifs envers moi pendant la dure de ce travail.
6 Remerciements
Acknowledgments
There is a number of people that played an important role in the accomplishment of this work to
whom I would like to express my gratitude.
I would like to thank Professor Tsichritzis, who followed my work from the very start, for
trusting me and providing me with the necessary support for this thesis. He allowed me not only
to accomplish this work but also gave me the opportunity to learn a lot.
I would like to thank Professor C. Pellegrini who by accepting the direction of this thesis
made it possible for me to carry out this work.
I would like to thank Professor A. Yonezawa for doing me the honor of accepting to be my
external reader and for his encouragement for this and future work.
There are several reasons for thanking Doctor O.M. Nierstrasz. To make a long story short,
I would like to thank him, among others, for getting me interested, a long time ago, in process
calculus, for reading and commenting on several earlier versions of this thesis and for being al-
ways ready to engage in stimulating discussions.
I would also like to thank L. Dami and J. Vitek for their encouragement, which has been
invaluable, and their acute comments and suggestions that allowed me to dramatically improve
the presentation of this work.
Finally, there is a large number of people, my parents and colleagues among others, that
had to endure the peculiar moods into which I was often driven during this period and whom I
would like to thank for their understanding.
Contents
Rsum 1
1 Introduction..................................................................................................................1
1.1 La Conception des Langages  Objets Concurrents...........................................1
1.2 La Spcification de la Smantique des Objets Actifs.........................................2
1.3 Contributions......................................................................................................3
2 Choix de Conception pour des Langages  Objets Concurrents.................................3
2.1 Le Modle dÕObjets............................................................................................4
2.2 Les Fils de Contrle............................................................................................4
2.3 LÕInteraction des Objets......................................................................................5
2.3.1 Emission des Requtes...............................................................................5
2.3.2 Acceptation des Requtes..........................................................................5
3 Comparaison des Choix de Conception.......................................................................6
3.1 Critres de Conception........................................................................................6
3.2 Evaluation des Choix de Conception..................................................................7
Modles dÕObjets............................................................................................7
Mcanismes dÕInteraction et Fils de Contrle................................................7
4 Description Smantique des Langages  Objets Concurrents......................................8
5 Conclusion...................................................................................................................9
CHAPTER 1
Introduction 11
1.1 Object-Oriented Programming...............................................................................12
Objects and Messages...................................................................................12
Classes and Class Inheritance.......................................................................13
Substitutability, Types, Subtypes and Polymorphism..................................13
1.2 Designing Concurrent Object-Oriented Languages...............................................15
1.3 Specifying the Semantics of Active Objects...........................................................17
1.4 Contributions..........................................................................................................18
1.5 Thesis Overview.....................................................................................................19
2 Contents
CHAPTER 2
Issues in the Design and Implementation of
the Concurrent Object-Oriented Language Hybrid 21
2.1 Overview of Hybrid................................................................................................22
Object Types.................................................................................................22
Object Interaction and Concurrency.............................................................23
2.2 The Concurrency Features......................................................................................26
2.2.1 Local Delays With Delay Queues..................................................................27
2.2.2 Remote Delays With Delegated Calls...........................................................28
2.2.3 Using Delegated Calls and Delay Queues for Local Delays.........................29
2.3 An Implementation of The Hybrid Concurrency Model........................................30
2.3.1 Implementing the Concurrency Model..........................................................32
2.3.2 Efficiently Supporting the Active View of Objects.......................................32
2.4 The Integration of the Concurrency and Object-Oriented Features........................33
2.4.1 Encapsulation and Intra-Object Concurrency................................................34
2.4.2 Combining Synchronization and Inheritance...............................................35
2.4.3 Data Abstractions with Concurrent Implementations....................................36
2.5 Summary.................................................................................................................37
CHAPTER 3
A Design Space for Concurrent OOPLs 39
3.1 A Design Space for Concurrent OOPLs.................................................................40
3.2 Concurrent Object Models......................................................................................40
3.3 Internal Concurrency..............................................................................................41
3.4 Constructs for Object Interaction............................................................................43
3.4.1 The ClientÕs View - Issuing Requests............................................................43
One-way Message Passing............................................................................44
Remote Procedure Call.................................................................................44
Proxies..........................................................................................................45
3.4.2 The ServerÕs View - Constructs for Accepting Requests..............................45
Unconditional acceptance.............................................................................45
Explicit acceptance.......................................................................................46
Activation conditions...................................................................................46
Reflective computation.................................................................................47
3.5 Classification of Existing Languages.....................................................................47
3.5.1 The Orthogonal Approach.............................................................................47
Smalltalk-80.................................................................................................47
Emerald........................................................................................................48
Trellis/Owl...................................................................................................49
ConcurrentSmalltalk....................................................................................51
SR.................................................................................................................53
3.5.2 The Heterogenous Approach.........................................................................55
PAL..............................................................................................................55
Contents 3
Eiffel //.........................................................................................................55
ACT++.........................................................................................................56
3.5.3 The Homogeneous Approach........................................................................58
ABCL/1........................................................................................................58
ABCL/R.......................................................................................................61
POOL-T and POOL2...................................................................................61
Hybrid..........................................................................................................62
SINA............................................................................................................63
3.6 Summary.................................................................................................................65
CHAPTER 4
Comparing the Design Alternatives with Respect to Software Reuse 69
4.1 Language Design Requirements for Reusability....................................................70
4.2 Comparing the Language Design Choices..............................................................71
4.2.1 An Example Application...............................................................................71
4.2.2 Exploring the Language Design Space..........................................................73
4.3 Concurrent Object Models......................................................................................73
4.4 Thread Structure and Object Interaction Mechanisms............................................73
4.4.1 Sequential Objects.........................................................................................74
RPC...............................................................................................................74
One-Way Message Passing...........................................................................75
Build-in Support for Courier Proxies............................................................76
More Flexible Request/Reply Mechanisms..................................................77
4.4.2 Multi-threaded Objects..................................................................................78
Quasi-Concurrent Approaches......................................................................78
Concurrent Approaches................................................................................79
4.5 Compositionality and Finer Grain Reuse................................................................80
4.6 Conclusions and Summary....................................................................................82
CHAPTER 5
A Unifying Framework for Process Calculus Semantics of
Concurrent Object-Based Languages and Features 85
5.1 Basic Framework: objects, classes and messages...................................................87
5.1.1 The Structure of Class Agents.......................................................................88
5.1.1.1 Program-Defined Classes.....................................................................88
5.1.1.2 Predefined Classes................................................................................89
5.1.2 Remarks.........................................................................................................89
5.1.3 The Structure of Program Defined Objects...................................................89
The Request Handler....................................................................................90
Instance Variables.........................................................................................90
Method Agents..............................................................................................91
The Method Scheduler..................................................................................91
Self................................................................................................................92
Objects..........................................................................................................92
4 Contents
5.2 Defining SCOOL, a Simple Concurrent Object-Oriented Language.....................92
5.2.1 Syntax and Informal Description of SCOOL................................................92
Expressions...................................................................................................93
Statements.....................................................................................................94
Declarations..................................................................................................94
5.2.2 Semantics.......................................................................................................94
Class Declarations.........................................................................................94
Variable Declarations...................................................................................95
Method Declarations.....................................................................................95
5.2.2.1 Expressions and Statements..................................................................96
Agents Representing Expressions.................................................................96
Statements and Sequential Composition.......................................................96
Semantics of Expressions.............................................................................97
Semantics of Statements...............................................................................98
5.2.2.2 Predefined Object Classes....................................................................99
Process Objects.............................................................................................99
Semaphores...................................................................................................99
Booleans........................................................................................................99
Integers........................................................................................................100
5.3 Accommodating Other Object Models.................................................................101
5.3.1 Modifying the Syntax..................................................................................101
Declarations................................................................................................101
Statements...................................................................................................102
Expressions.................................................................................................102
5.3.2 Semantics.....................................................................................................102
Class Declaration........................................................................................102
Method Scheduling.....................................................................................102
Semantics of Statements.............................................................................102
5.4 Class Inheritance...................................................................................................102
5.4.1 Extending SCOOL to Support Inheritance..................................................104
5.4.2 Agent Definitions for Modelling Class Inheritance.....................................104
Semantics of Class Declarations.................................................................106
5.4.3 Overriding Superclass Methods, Self and Super.........................................106
5.5 Considering Other Process Calculi......................................................................107
5.5.1 Modelling COOPL Features in the  -Calculus............................................108
5.5.2 Using  -Calculus Ports to Represent Object Identifiers..............................109
5.5.3 Comparing Object Identifiers......................................................................110
5.5.4 Primitive Objects and the Semantics of Expressions...................................110
5.6 Concluding Remarks.............................................................................................112
CHAPTER 6
Conclusion 115
6.1 Summary...............................................................................................................116
6.1.1 Language Design Framework......................................................................116
6.1.1.1 Understanding the Language Choices................................................116
Contents 5
Object Models.............................................................................................116
Object Threads............................................................................................116
Object Interaction.......................................................................................117
6.1.1.2 Language Design Criteria...................................................................117
6.1.2 Evaluating Design Choices and their Combinations..................................118
Request and Reply Scheduling...................................................................118
Internal Concurrency..................................................................................119
6.1.3 Formally Specifying the Semantics of COOPLs and of Active Objects.....119
6.2 Open Problems and Future Research Directions..................................................120
6.2.1 Taking Advantage of Class Inheritance in COOPLs...................................120
6.2.2 Object Behavior, Behavioral Equivalence and Substitutability...................121
6.2.3 Types as Behavioral Constraints for Active Objects...................................122
References 125
Rsum
1 Introduction
La programmation par objets est une mthode de programmation qui consiste  construire des
logiciels structurs  lÕaide dÕun ensemble dÕobjets cooprants qui inter-agissent pour raliser
les fonctions du logiciel. Cette approche de programmation suscite un intrt croissant dans plu-
sieurs domaines de lÕinformatique car, dÕune part, elle fournit un ensemble de concepts unifica-
teurs permettant dÕintgrer plusieurs techniques de programmation dont les bnfices sont dj
largement reconnus, dÕautre part, elle offre la possibilit de pouvoir rutiliser les objets, qui sont
des entits relativement autonomes, dans diverses applications.
Les bnfices de cette mthode de programmation pour la construction du logiciel sont ex-
ploits par lÕutilisation des langages de programmation  objets, qui rendent aise la program-
mation selon cette mthode, ainsi que par des mthodes de conception, outils et environnements
de programmation qui ont comme but dÕ appliquer,  grande chelle, cette approche pour la ru-
tilisation du logiciel.
La motivation de ce travail est dÕlargir le domaine dÕapplication de cette mthode de pro-
grammation et permettre de tirer parti de ses bnfices dans la construction des systmes con-
currents. Ceci ncessite la conception de langages de programmation  objets concurrents qui
intgrent les concepts de la programmation par objets  ceux de la programmation concurrente,
ainsi que le dveloppement dÕoutils pour la description, dÕune manire rigoureuse, de la sman-
tique de ces langages et du comportement des objets concurrents afin de permettre leur rutili-
sation effective.
1.1 La Conception des Langages  Objets Concurrents
Un grand nombre de notations a t utilis pour la programmation concurrente. De plus, il y plu-
sieurs faons de combiner les concepts et les notations de la programmation concurrente  ceux
de la programmation par objets. Le problme qui se pose pour la conception des langages  ob-
jets concurrents est que une combinaison arbitraire des notations pour la programmation par ob-
2 Rsum
jets et la programmation concurrente, ne posant pas de difficults au niveau syntaxique, ne per-
met pas lÕintgration au niveau des concepts ce qui est necessaire pour tirer les bnfices de la
programmation par objets pour la construction du logiciel concurrent. Ce problme provient de
la non-orthogonalit des concepts sous-jacents  ceux deux types de programmation.
Afin, de concevoir des langages de programmation qui permettent dÕintgrer la program-
mation par objets et la programmation concurrente il est ncessaire dÕtudier lÕ inter-action des
concepts sous-jacents  ces deux types de programmation et de dvelopper des critres permet-
tant dÕvaluer les diverses possibilits concernant le choix des notations.
1.2 La Spcification de la Smantique des Objets Actifs
Le dveloppement de modles pour la description de la smantique des langages  objets con-
currents,  part dÕtre un but en soi, prsente un intrt tout particulier dans le cadre de la pro-
grammation concurrente par objets en ce qui concerne, en vue de leur rutilisation, la description
rigoureuse du comportement des objets dvelopps  lÕaide des langages  objets concurrents,
que lÕon appellera par la suite objets actifs.
La description de la smantique des langages  objets concurrents et du comportement des
objets actifs nÕa fait lÕobjet que dÕun nombre restreint de travaux de recherche. De plus, dans ces
travaux les points suivants nÕont t traits que dÕune faon limite:
¥ La description dans un seul modle de lÕensemble des concepts de la programmation
concurrente par objets permettant une tude rigoureuse de leur interaction. Les appro-
ches antrieures nÕont pas pris en compte la description de smantique de lÕhritage.
¥ Le dveloppement dÕun modle permettant la description et comparaison des langa-
ges  objets concurrents adoptant des approches de conception diffrentes. Les descrip-
tion smantiques se sont limites  un seul langage. Il est difficile de gnraliser ces ap-
proches pour la description de la smantique dÕautres langages, surtout dans le cas o ils
sont bass sur des approches de conception diffrentes.
¥ Spcifier la smantique des dfinitions dÕobjets dÕune faon indpendante de la sman-
tique des programmes dans lequel elles apparaissent de sorte quÕelle puisse tre utilise
comme reprsentation rigoureuse du comportement dÕobjets et permettre dÕtablir la
compatibilit des comportements. Ce point est essentiel afin de permettre la rutilisation
des objets est de bnficier de lÕabstraction des donnes.
Rsum 3
1.3 Contributions
Les principales contributions de cette thse sont: (1) Un cadre conceptuel pour lÕtude de lÕinter-
action de la programmation  objets et de la programmation concurrente permettant lÕvaluation
des diffrentes approches de conception. (2) Un cadre formel pour la description de la smanti-
que des langages  objets concurrents permettant de spcifier et comparer la smantique des lan-
gages bass sur des approches de conception diffrentes et dÕtablir une notion formelle de com-
portement pour les objets actifs. Les points suivants rsument les contributions spcifiques:
¥ Une tude de cas concernant lÕintgration des concepts de la programmation par objets et de
la programmation concurrente, effectue sur le langage Hybrid, qui a permis dÕexaminer
dÕune faon concrte lÕeffet des choix de conception sur lÕintgration de ces concepts.
¥ Une description de lÕespace des choix de conception pour les langages  objets concurrents
permettant de reprsenter les possibilits de combiner les concepts de la programmation con-
currente a ceux de la programmations  objets.
¥ Un ensemble des critres permettant lÕvaluation des choix de conception par rapport  lÕin-
tgration des concepts de la programmation par objets  ceux de la programmation concurren-
te.
¥ LÕidentification dÕun ensemble de faons de combiner certains choix de conception qui satis-
font ces critres.
¥ Le dveloppement dÕune approche cadre pour la description formelle de la smantique des
langages  objets concurrents permettant de:
¥ Reprsenter les concepts de programmation  objets et de la programmation concurrente.
¥ Obtenir une notion formelle de comportement pour les objets actifs.
¥ Etablir des notions formelles de compatibilit de comportement.
2 Choix de Conception pour des Langages  Objets Concurrents
Pour pouvoir comparer le grand nombre des possibilits pour la conception des langages  objets
concurrents nous avons choisit de reprsenter les choix de conception en considrant les trois
aspects suivants:
¥ Le modle dÕobjets: La prise en compte de lÕexcution concurrente dans le concept dÕobjet
¥ Les fils de contrle des objets: Le nombre, la cration et commutation des fils de contrle 
lÕintrieur des objets
4 Rsum
¥ LÕinteraction des objets: les mcanismes et notations permettant de spcifier lÕenvoi et la r-
ception de messages par les objets.
2.1 Le Modle dÕObjets
On distingue les trois approches suivantes concernant la prise en compte de lÕexcution concur-
rente dans les objets:
¥ Orthogonale: le concept dÕobjet est indpendant des concepts de la programmation concur-
rente. Les objets sont des entits passives dont les oprations sont excutes par des fils de
contrle concurrents.
¥ Homogne: Les objets sont considrs comme des entits actives qui reoivent des requtes
pour lÕexcution de leurs oprations quÕils excutent en temps opportun.
¥ Htrogne: Il y a des objets passifs et des objets actifs. Le langage assure la protection des
objets passifs en interdisant la construction de programmes o les oprations des objets pas-
sifs peuvent tre excuts par des fils de contrle concurrents.
2.2 Les Fils de Contrle
En considrant le nombre et la commutation des leurs fils de contrle on caractrise les objets
comme:
¥ Squentiels: Un seul fil de contrle correspond  chaque objet.
¥ Quasi-concurrents: Un seul fil de contrle est actif  lÕintrieur dÕun objet et la commutation
des fils de contrle est spcifie par le programmeur.
¥ Concurrents: Il y a plusieurs fils de contrle sÕexcutant, dÕun point de vue conceptuel, en pa-
rallle.
La cration des fils de contrle  lÕintrieur des objets peut se drouler suivant deux faons
non exclusives:
Par rception de message: la cration des fils de contrle est initie par la rception dÕun mes-
sage.On distinguera deux sous-cas exclusifs concernant la cration des fils de contrle par r-
ception de message:
¥ Cration contrle: la cration de fils de contrle peut tre contrle par lÕobjet.
¥ Non-contrle:la cration de fils de contrle se passe automatiquement  lÕarrive dÕun
message.
Rsum 5
¥ cration explicite: la cration des fils de contrle a lieu par lÕexcution, par un fil de contrle
actif, dÕune instruction prvue  cet effet.
2.3 LÕInteraction des Objets
Pour examiner les mcanismes permettant lÕinteraction des objets on va considrer sparment
les cas dÕmission et de rception des requtes par les objets se trouvant, respectivement, dans
les rles de client et serveur.
2.3.1 Emission des Requtes
On distingue entre les mcanismes qui incorporent ou non une notion de rponse  une requte:
¥ One-way messages: la notion de rponse nÕest pas prise en compte par ces mcanismes. LÕen-
voi et obtention de rponse a lieu  travers des messages qui au niveau du langage ne se dif-
frencient pas des messages utiliss pour des requtes.
¥ Request/Reply: Ces mcanismes incorporent une notion de rponse  une requte. Il y a cepen-
dant des variations considrables en ce qui concerne le contrle qui peut tre exerc par le cli-
ent pour lÕobtention de la rponse. On distingue les catgories suivantes de mcanismes re-
quest/reply:
¥ Remote procedure call: le client doit attendre pour lÕobtention de la rponse de manire
synchrone.
¥ Par Proxies: le client ne pas obliger dÕattendre la rponse, des objets intermdiaires, plus
ou moins explicites, sont utilises comme pour lÕobtention de la rponse. Le client ob-
tient la rponse, de manire asynchrone par rapport au serveur, par ces objets intermdi-
aires.
2.3.2 Acceptation des Requtes
On distingue entre acceptation conditionnelle et non-conditionnelle. LÕ acceptation non-condi-
tionnelle se caractrise par lÕabsence de mcanismes pour contrler lÕacceptation des requtes.
La rception dÕun message a comme effet lÕexcution de lÕopration correspondante conforme-
ment aux proprits des fils de contrle des objets.
Les approches suivantes peuvent tre utilises dans le cas de lÕacceptation conditionnelle
pour contrler lÕacceptation des requtes:
¥ Acceptation explicite: lÕacceptation a lieu par lÕexcution dÕune instruction par un fil de con-
trle de lÕobjet spcifiant explicitement les requtes  accepter.
6 Rsum
¥ Conditions dÕactivation: Les oprations sont associes  des conditions sur lÕtat de lÕobjet
qui doivent tre satisfaites pour lÕacceptation et excution dÕune requte. Les conditions sont
spcifiques  la reprsentation si elle font rfrence aux variables dÕinstance de lÕobjet ou
abstraites si elles utilisent une autre approche pour dterminer lÕtat de lÕobjet.
¥ Rflection: la rception dÕun message dclenche lÕexcution dÕune opration dans un mta-
objet. Le mta-objet peut examiner le contenu du message et lÕtat de lÕobjet et en consquen-
ce excuter lÕopration correspondante ou mettre le message dans une file dÕattente.
3 Comparaison des Choix de Conception
Afin de comparer les diffrents choix de conception et leur combinaisons nous avons dvelopp
une srie de critres dÕvaluation. Ces critres sont bass sur le principe que le langage devrait
rendre aise la ralisation dÕobjets qui opreront correctement en imposant un minimum de res-
trictions sur leur environnement dÕutilisation et sur le comportement des objets avec lesquels ils
seront amens  interagir.
3.1 Critres de Conception
Un langage de programmation  objets offrant une intgration adquate des concepts de la pro-
grammation par objets et ceux de la programmation concurrente devrait remplir les conditions
suivantes:
1.Protection, exclusion mutuelle: LÕintgrit de lÕtat des objets doit tre protge des ap-
pels concurrent
2.Transparence de lÕordonnancement dÕacceptation des requtes: Il doit tre possible
dÕordonnancer lÕacceptation des requtes en utilisant les informations relatives  la re-
qute et  lÕtat de lÕobjet. LÕordonnancement des requtes doit tre, dans la mesure du
possible, invisible aux objets clients.
3.Concurrence intra-objet: Il doit tre possible dÕutiliser la concurrence intra-objet dans la
ralisation des objets afin de permettre lÕacceptation de plusieurs requtes concurrentes
ou de raliser la fonctionnalit des objets par des algorithmes parallles. De plus, la con-
currence intra-objet doit tre invisible aux clients de lÕobjet.
4.Transparence de lÕordonnancement dÕacceptation des rponses: Il doit tre possible de
permettre lÕordonnancement flexible de lÕobtention des rponses sans que cela implique
la coopration des objets appels.
Rsum 7
5.Compositionalit, programmation incrmentale: Outre le fait quÕil doit tre possible de
dvelopper des objets rutilisables dans diffrentes applications, les notations utilises
pour la programmation concurrente doivent pouvoir se combiner avec le mcanisme de
lÕhritage et favoriser la programmation incrmentale.
3.2 Evaluation des Choix de Conception
Pour lÕvaluation des choix de conception et de leurs combinaisons, effectue dans le chapitre
4, on se sert dÕun exemple dÕapplication concurrente qui nous permet dÕidentifier et dÕillustrer
des situations o certains choix de conception sÕavrent inadquats par rapport  nos critres.
Procdant ainsi, Òpar liminationÓ on arrive  lÕidentification dÕun ensemble des combinaisons
des choix de conception qui satisfont nos critres de conception que lÕon prsente ci dessous.
Modles dÕObjets
Concernant le modle dÕobjets, cÕest lÕapproche homogne qui est la plus satisfaisante. Elle
remplit dÕune part la condition (1) en assurant automatiquement la protection de lÕtat interne
des objets vis  vis des appels concurrents, dÕautre part la condition (5) en supportant, au con-
traire de lÕapproche htrogne, une seule sorte dÕobjet pouvant tre utilise dans toutes les ap-
plications.
Mcanismes dÕInteraction et Fils de Contrle
Les conditions (2) et (4) concernant lÕordonnancement des requtes et des rponses, peuvent tre
satisfaites par tous les choix concernant les fils de contrle pourvu quÕils soient combins avec
un choix appropri des mcanismes dÕinteraction dÕobjets.
Dans le cas des objets squentiels, nÕayant quÕun seul fil de contrle, il est ncessaire dÕa-
voir un mcanisme qui permette de retarder lÕexcution dÕune requte et dÕobtenir la rponse aux
requtes sans suspendre lÕexcution du fil de contrle. La meilleure approche dans ce cas est de
combiner les messages  sens unique avec lÕappel de procdure  distance (RPC). Ceci permet
 un objet de tirer avantage dans son implantation des la flexibilite des messages  sens unique
tout en prsentant  ses clients une interface RPC. En ce qui concerne lÕordonancement des r-
ponses il serait aussi envisageable dÕutiliser une approche base sur des proxies, nanmoins il
faudrait un mcanisme permettant de combiner lÕordonancement des requtes et des rponses,
ce qui fait dfaut dans les approches  base de proxies que nous avons examines.
Dans le cas des objets concurrents et quasi-concurrents, afin de permettre de satisfaire les
conditions (3) et (4) il est ncessaire de combiner le choix de RPC, utilis comme le mcanisme
principal pour lÕinter-action des objets, soit avec la cration explicite de fils de contrle soit avec
8 Rsum
des messages  sens unique ou des proxies pour permettre  un fil de contrle dÕmettre des re-
qutes pouvant tre excutes en parallle.
Dans le cas dÕobjets quasi-concurrents, afin de permettre lÕordonnancement des rponses
(4), le blocage dÕun fil de contrle suite  un appel en RPC ou pour lÕobtention dÕune rponse
par lÕintermdiaire dÕun proxy, doit entraner la commutation dÕun autre fil de contrle.
La concurrence intra-objet peut tre supporte de manire satisfaisante soit par les objets
concurrents soit par la ralisation de la fonctionalit dÕun objet par un ensemble dÕobjets concur-
rents, pourvu que le choix des mcanismes dÕinteraction dÕobjets soit adquat pour lÕordonann-
cement des requtes et des rponses et que la smantique du langage soit telle quÕun objet im-
plante par un ensemble dÕobjets concurrents soit substituable dans tout contexte avec un objet
unique offrant la mme fonctionalit  ses clients.
Ces deux approches pour la concurrence intra-objet sont complmentaires et il est intres-
sant de les avoir dans un mme langage afin de pouvoir les utiliser dans les situations auxquelles
elles conviennent le mieux. LÕapproche des objets concurrents rend trs facile la ralisation des
objets qui acceptent, en parallle, plusieurs requtes qui ne modifient pas lÕtat de lÕobjet. La ap-
proche multi-objet est intressante pour raliser la fonctionnalit dÕune classe dÕobjets en utili-
sant des objets de classes existantes.
4 Description Smantique des Langages  Objets Concurrents
Pour la description de la smantique des langages  objets concurrents nous avons pris lÕappro-
che, utilise par Milner dans [58], qui consiste  spcifier la smantique dÕun langages concur-
rents par ÒtraductionÓ au calcul des processus CCS. La spcification de la smantique des lan-
gages de programmation selon cette approche, quoique oprationelle, a une forte ressemblance
aux approches dnotationelles[35][74][78]. La spcification de la smantique dÕun langage de
programmation est donne comme une fonction faisant correspondre  chaque construction syn-
taxique du langage un terme du calcul des processus, le ÒsensÓ des constructions syntaxiques
composes tant dfini en faisant appel  celui de ses composantes directes.
Afin de simplifier la description de la smantique des langages et de permettre de repr-
senter et comparer les divers choix de conception de langages, nous avons tabli un ensemble de
conventions pour la reprsentation des concepts de la programmation par objets concurrents en
CCS, et nous avons dfini, en tant que processus parametrises par des processus, un ensemble
dÕoprateurs CCS drives permettant de capter directement les concepts de la programmation
concurrente par objets.
Rsum 9
Nos choix concernant la reprsentation des concepts de la programmation par objets en
CCS ont t faits de faon  permettre de dcrire facilement et de comparer la smantique de
langages bass sur des choix de conception diffrents. Ainsi, lÕensemble de rgles de reprsen-
tation et les dfinitions dÕoprateurs drivs fournissent un cadre gnral pour la description s-
mantique formelle des langages de programmation  objets concurrents. La dfinition dÕun en-
semble de langages nous a permis dÕillustrer lÕapproche pour la reprsentation dÕun grand nom-
bre de concepts de la programmation concurrente par objets comprenant aussi lÕhritage dont la
smantique nÕavait pas t spcifie, auparavant, dans un mme cadre que les notations pour la
programmation concurrente afin de permettre dÕtude de leur interaction.
Cette approche pour la description smantique a aussi le bnfices de pouvoir tirer avantage
du formalisme du calcul de processus CCS afin dÕtudier la conception des langages et le com-
portement des objets. Une consquence importante de ceci, ainsi que du fait que la smantique
du comportement dÕune classe est spcifi par un processus CCS, est quÕon obtient une notion
formelle de comportement et dÕquivalence de comportement des objets induite par lÕquivalen-
ce des processus CCS correspondants.
5 Conclusion
Afin de pouvoir utiliser la programmation par objets et tirer ses bnfices pour la construction
dÕapplications concurrentes, il est essentiel dÕune part, dÕavoir des langages de programmation
permettant une intgration adquate des concepts de la programmation concurrente  ceux de la
programmation par objets, et dÕautre part, dÕavoir des outils formels qui permettent la descrip-
tion rigoureuse de la smantique de ces langages, et qui fournissent des notions formelles du
comportement et de la compatibilit du comportement des objets.
Concernant la conception des langages de programmation  objets concurrents, nous avons
tudi lÕinteraction des concepts de la programmation par objets et de la programmation concur-
rente et produit un cadre conceptuel permettant dÕvaluer les choix de conception des langages.
En utilisant ce cadre on a identifi un ensemble de combinaisons de choix de conception pour
les langages  objets concurrents offrant une intgration adquate de ces concepts.
Pour la description de la smantique des langages  objets concurrents nous avons produit
une formalisation des concepts de la programmation  objets concurrents dans le calcul de pro-
cessus CCS permettant la description formelle des divers choix de conception et qui a permis
dÕ obtenir des notion formelle, essentielles en vue de leur rutilisation, du comportement et de
compatibilit de comportement des objets concurrents.
CHAPTER 1
Introduction
Object-Oriented (OO) programming [25][34][56][64] has become extremely popular for the de-
sign and construction of software systems. It is a programming approach that advocates the con-
struction of systems structured as a collection of interacting software objects that reflect their
application domain counterparts. It also provides a framework that encompasses a host of pro-
gramming techniques such as modularity, encapsulation, data abstraction, polymorphism and in-
heritance that are useful for the construction and maintenance of software and that promote soft-
ware reusability[12]. The full deployment of OO techniques and their potential for software re-
usability[57][82] is best achieved on one hand by the use of object-oriented programming
languages (OOPL) which directly support the object-oriented concepts and on the other by de-
sign methods [30][40][89], techniques and tools [33] that aim at larger-scale reuse and assist the
construction and dissemination of reusable software.
The motivation of this work is to take advantage of object-oriented programming tech-
niques and their potential for software reusability for the construction of concurrent software
systems. There are two important issues to consider for approaching this goal. The first is the
design of Concurrent Object-Oriented Programming Languages (COOPLs) that integrate the
object-oriented techniques with concurrent programming. The second is the development of se-
mantic models that provide a rigorous basis for the design and development of concurrent sys-
tems following an object-oriented approach.
The problem that is posed by the design of COOPLs is that issues of concurrency, contrary
to what one might naively expect, are not orthogonal to object-oriented concepts. The interfer-
ence of the concurrency and object-oriented features makes it hard to achieve their satisfactory
integration.
Object-Oriented Programming
12
The development of semantic models for the description of the semantics of concurrent ob-
ject-oriented features is important both for analyzing the various language features and for the
rigorous description of the behavior of active objects. A rigorous way to describe the behavior
of active objects independently of particular implementations is crucial in order to be able to re-
use objects across applications.
In section 1.1 we review the main concepts underlying object-oriented programming and
the benefits entailed by following an OO approach for software development. The purpose of
this section is to provide some background on object-oriented programming and set up the stage
for presenting in 1.2 and 1.3 the problems addressed by this work. Namely, the design of
COOPLs and the development of models for the semantic description of OO languages and sys-
tems.
1.1 Object-Oriented Programming
Object-oriented programming is a programming approach that views software systems as col-
lections of objects interacting by exchanging messages. Central to the approach are the concepts
of object and message.
Objects and Messages
An object is an identifiable entity, usually modelling an application domain counterpart, that
supports a number of operations. The set of supported operations, also called methods, consti-
tutes the objectÕs interface and determines what one can do with the object, e.g. use a service
provided by it, find out about or modify the state of the application domain entity modelled by
the object. To invoke an objectÕs operation one sends a message requesting it to execute its op-
eration and, eventually, return a result.
The message metaphor is used to emphasize that the caller has no control over the exact
actions that are performed at the receiver object. This is realized by the means of delayed binding
where the code executed is determined not only by the requested operation but also by the way
that the operation is implemented by the receiver.
The state of an object persists during its entire lifetime and is maintained in the objectÕsin-
stance variables. The scope of instance variables is confined to the objectÕs operations so that
updates or inquiries concerning the objectÕs state may only take place indirectly by invoking an
appropriate operation. This encapsulation of the objectÕs state and operations has several bene-
fits:
Chapter 1 13
¥ It enhances modularity [70][71] by establishing and enforcing well defined boundaries
between objects at the operation interface. Furthermore, the modular decomposition of a
system is in terms of objects that represent entities of the application domain. This pro-
duces modular units that are more likely to be reused across application than modules
that occur from the decomposition of an applicationÕs functionality for managerial pur-
poses.
¥ It provides support for data abstraction [49] by insulating the programs that use objects
from the way that objects are implemented and protecting the integrity of the object state.
Data abstraction supports programming at a higher level of abstraction and the possibil-
ity to modify or extend the implementation of objects without affecting already devel-
oped programs that used them.
Classes and Class Inheritance
Classes specify the structure of objects and the implementation of their operations and act as
templates for the creation of instances of the class.
Class inheritance is a mechanism that may be used for the incremental definition of a class
in terms of some already defined classes that are called its superclasses or parent classes. The
newly defined class is called a subclass of its superclasses. If no more than one parent class may
be used in defining the class then the inheritance mechanism is called single inheritance and
multiple inheritance otherwise.
Class inheritance allows class definitions to be reused in the definition of new classes and
has been considered as a criterion to characterize a language as object-oriented [87]. However,
it has been a source of problems because of the way that it has been included in some program-
ming languages. As discussed by Snyder in [75] the encapsulation of objects, which is an essen-
tial feature of object-oriented programming, is violated by the inheritance mechanism of some
languages. Other problems are, as will see in the next section, caused by using the class inherit-
ance hierarchy for defining the type systems of some object-oriented languages and, as we dis-
cuss in section 1.2, its interference with the concurrency mechanisms in the case of COOPLs.
Substitutability, Types, Subtypes and Polymorphism
Late binding makes it possible to write programs that operate on objects of any class provided
that the operations required by the programs are supported by the class and that the behaviors
provided by the classes are compatible in some sense. This idea is known as the principle of sub-
Object-Oriented Programming
14
stitutability. Any object may be used in a program context for which it supports the required op-
erations and behavior independently of the way it is implemented.
With untyped object-oriented languages any object may be used in any program context
and it is the responsibility of the programmer to prevent run-time errors by ensuring that objects
satisfy the requirements of substitutability. Typed object-oriented languages assist the program-
mer through compile time type-checking to ensure, to some extent, that objects satisfy the sub-
stitutability requirements.
Unlike classes which provide the information necessary for the creation of their instances,
types are motivated by compile time type-checking and express constraints on the objects usable
in some program context. Depending on the notion of types supported, object-oriented languag-
es express different notions of object compatibility that vary in their ability and flexibility to cap-
ture substitutability. Several such notions of compatibility are discussed by Wegner and Zdonik
in [88] for examining various forms of incremental modification supported in object-oriented
languages. Two of these are signature compatibility and behavior compatibility.
Signature compatibility is based on the signature of operations applicable to the objects of
the type and is behind most notions of object-oriented types. Type-checking based on signature
compatibility will ensure that objects support all the operations, with the appropriate number of
arguments and compatible argument types, that are required in some program context.
Behavior compatibility is a semantic notion and it can be expressed by associating an alge-
bra with the signature of the type [88] or axiomatically[6][37] by associating operations with
preconditions and postconditions on some abstract representation of the states of the objects of
the type.
A type system is polymorphic[26] if objects may satisfy the constraints required by more
than one type specification. In such a type system a type S is called a subtype of a type T if every
object that qualifies as an object of type S also qualifies as an object of type T. Polymorphic type
systems are very important for object-oriented programming. They can be used for making sure
at compile time that the requested operations are effectively supported by the invoked object
without imposing any further constraint on the objectÕs class.
In practice the approaches that have been followed by strongly typed object-oriented lan-
guages are the following:
¥ Collapse the notion of type with that of a class and use the class-subclass relationship as
a subtype relationship.
Chapter 1 15
¥ Specify types in terms of the signatures of the supported operations and use some notion
of signature compatibility motivated by substitutability to specify type compatibility and
subtypes.
¥ Use some form of signature compatibility augmented by some means to specify more
about the semantics of the type. This is done to allow the programmer to associate more
semantic information with signatures to prevent cases where the signatures of different
object classes are accidentally compatible. This approach is illustrated by POOL-I[7].
The approach that identifies types with classes and subtyping with inheritance makes type-
checking easy but has drawbacks. It unduly restricts substitutability and constrains the use of
class inheritance. There may be classes that are not in a class-subclass relationship that are sig-
nature and behaviorally compatible, however, instances of such classes are not interchangeable.
With respect to the use of class inheritance for code reuse, the substitutability principle requires
subclasses to inherit and provide to their clients all the superclassÕs methods although just some
may be useful for defining the subclass.
Type systems incorporating the notions of types discussed, their use in object-oriented lan-
guages and their underlying theory are presented in [20]and [26]. Wegner and Zdonik in [88]
discuss the relation between types, classes, inheritance and subtyping. Some of the drawbacks
of identifying subtyping and inheritance in a language are discussed in [41].
1.2 Designing Concurrent Object-Oriented Languages
To make use of object-oriented techniques for constructing concurrent applications it is neces-
sary to provide a way to express concurrent execution and synchronization in a object-oriented
language. This may be accomplished by using a variety of concurrent programming nota-
tions[9]. Furthermore, there are various ways in which these notations have been, or may be,
combined with OO constructs in COOPLs[69].
However, arbitrary combinations of concurrency and object-oriented features may not pro-
duce the desired effect. Issues of concurrency are not orthogonal to object-oriented ones and, as
has been noticed recently by a number of researchers [17][41][68][80], the interference of con-
currency and object-oriented features defeats the purpose of object-oriented techniques for the
development of concurrent software.
A first approach that may come to oneÕs mind for the design of a COOPL is to introduce in
a object-oriented language the notion of concurrent process and some mechanism for process in-
teraction independently of objects. With this approach there are two independent concepts: con-
Designing Concurrent Object-Oriented Languages
16
current processes and objects, in terms of which applications may be structured. The disadvan-
tage of such an approach is that it weakens modularity. The boundaries of the system compo-
nents produced from applying each concept independently may intersect so that neither of the
two structuring concepts may produce self-contained modular units. As the process communi-
cation-synchronization boundary may be different from the object interface, objects cannot be
implemented independently from the process structure of an application. For instance, objects
should be implemented differently according to whether they are used in a program where they
will be shared by concurrent processes. Shared objects should be implemented in such a way that
their internal state is protected from the concurrent invocation of their methods.
A second approach is to integrate the concepts of object and process into the concept of ac-
tive object having its own single thread of control. This has the benefit that there is a single con-
cept for structuring applications and shows better modularity. However, it restricts the number
of threads that can be used to implement objects and it may thus weaken the power of data ab-
straction when multiple threads are needed for the objectÕs implementation. In principle it would
be possible to use objects to represent internal control threads, however as we will see depending
on the features supported by a language this approach for the implementation of objects may not
always be hidden behind an objectÕs interface and weakens thus the support for data abstraction.
Another aspect to consider in the design of the concurrency constructs and their integration
with object-oriented features is the use of class inheritance. Depending on the design of the con-
currency constructs of the language class inheritance may be useless because all inherited meth-
ods may have to be rewritten. In other cases, in order to properly synchronize the execution of
methods defined in a subclass with inherited methods, subclasses have to access the instance
variables of their superclass, thus violating encapsulation. In some approaches it is attempted to
separate the concurrency constructs from the code of the methods so that inheritance may still
be used for the ÒsequentialÓ part of the object. Yet, in other approaches it is attempted to specify
independently, reuse and specialize the specification of synchronization policies for the execu-
tion of methods.
In order to develop languages that achieve a graceful integration of concurrency with ob-
ject-oriented features it is essential to have a deeper understanding of the interaction of the issues
of concurrency with the object-oriented concepts and to develop criteria for establishing their
integration. The various language design approaches may then be compared by their impact on
the integration of concurrent programming with object-oriented techniques in several aspects of
language design.
Chapter 1 17
An approach that may be followed for evaluating whether the different design choices pro-
vide satisfactory support for object-oriented programming is to construct examples that show
that the features under examination fail to support object-oriented techniques. With this ap-
proach we are able to identify constructs and combinations of constructs that are inadequate for
concurrent object-oriented programming. However, this approach for evaluating languages re-
quires to construct appropriate examples and uses of the language that reveal the interference of
features or their inadequate support for object-oriented techniques in various aspects of the lan-
guage design. This in some cases may only be possible after a language has been designed and
implemented. The development of a semantic framework for COOPL, discussed in the next sec-
tion, will be useful for providing a more rigorous approach for examining the interaction of fea-
tures and representing and comparing the various design alternatives.
1.3 Specifying the Semantics of Active Objects
Apart from the fact that the semantic description of COOPLs, and object-oriented features more
generally, is an interesting problem in its own right, several practical benefits, discussed below,
are to be drawn from a semantic model for describing the behavior of active objects.
Semantic descriptions of COOPLs have been scarce. Furthermore, the following important
issues underlying the semantics of concurrent object-oriented programming have been ad-
dressed, if at all, to a limited extent:
¥ The description of the semantics of the full range of object-oriented features so that it is
possible to examine their interaction in a formal setting. For instance inheritance has not
been taken into account in previous semantic descriptions of COOPLs.
¥ A framework in which the different design approaches taken by COOPLs may be cap-
tured and compared. Most semantic descriptions have concentrated on a particular lan-
guage and it is not clear whether and how languages based on different design approach-
es may be accommodated within the same semantic framework.
¥ The semantics should assign meanings to individual objects rather than complete pro-
grams. Moreover, the meaning assigned to objects should be useful as a notion of behav-
ior that abstracts from their implementation and should allow various notions of behav-
ioral compatibility among objects to be developed.
The last point is extremely important for taking advantage of object-oriented techniques for
developing concurrent systems. In order to reuse objects, take advantage of principle of substi-
Contributions
18
tutability and describe behavioral dependencies among components of application frameworks
a clear notion of object behavior is needed.
The approach that we have taken for the semantic description of COOPLs which fully ad-
dresses the first two points assigns as the meanings of individual objects terms of the Calculus
of Communicating Systems (CCS)[58]. This allows us to use all the underlying formal frame-
work for discussing the issues of behavior compatibility, substitutability and expressing and ver-
ifying behavioral constraints for objects.
1.4 Contributions
The main contributions of this thesis are: (1) A conceptual framework for understanding the in-
teractions of concurrency and object-oriented features and for comparing language design choic-
es with respect to the integration of concurrency and object-oriented programming; (2) A formal
framework for describing the semantics of a wide range of COOPLs and for providing a rigorous
notion of behavior for active objects. The points below summarize the specific elements of these
contributions.
¥ A case study of the integration of concurrency and object-oriented features in the language
Hybrid that concretely shows the effect of language design choices in integrating concurrent
and object-oriented programming. It identifies both choices that are problematic because of
the interference between features as well as choices that achieve a successful integration of
concurrency and object-oriented concepts.
¥ A design space for COOPLs that captures the different approaches for the combination of con-
currency and object-oriented features.
¥ A set of requirements for evaluating the support provided by COOPLs for object-oriented pro-
gramming and for comparing the different design approaches.
¥ A set of guidelines for the combination of design choices that successfully address the above
requirements.
¥ The development of a formal framework for describing the semantics of COOPLs that:
¥ Captures the standard OO features and concurrency and the different language design ap-
proaches.
¥ Models the semantics of individual object classes by CCS agents providing thus a rigor-
ous notion of object behavior and behavior equivalence induced from agent equivalence.
Chapter 1 19
¥ Makes possible to use the underlying CCS theoretical framework to reason about the be-
havior of objects.
1.5 Thesis Overview
Chapter 2 discusses in more detail the difficulties of integrating concurrency and object-oriented
programming. The discussion is carried out with respect to a particular language, Hybrid[62],
and is based on our own experience gained through our participation in the design and imple-
mentation of a prototype for this language[42][68].
In chapter 3 , in order to understand what are the different ways for combining concurrency
and OO features, we develop a design space capturing the essentially different approaches for
the design of COOPLs with respect to three separate aspects of language design. We then survey
a number of existing languages and state where they are situated in this design space.
Chapter 4 presents a list of requirements for the design of COOPLs to achieve a successful
integration of concurrency and object-oriented programming. Then, we explore the design space
presented in chapter 3 and examine how these requirements are addressed by the various design
choices. A number of examples and re-use scenarios are used for identifying the inadequacy of
certain design choices from an OO programming point of view.
Chapter 5 addresses the problem of the formal description of the semantics of object behav-
iors and the semantics of COOPLs. We take the approach of giving the semantics of objects by
translation to terms of a process calculus. We propose a framework, based on CCS[58], for such
a semantics and show how the different design choices discussed in chapter 3 can be accommo-
dated.
In chapter 6 we discuss a number of promising directions for future research. These include
the development of behaviorally motivated conformance relations for objects, further use of the
framework discussed in chapter 6 to more rigorously compare language and application designs
with respect to their re-use potential.
CHAPTER 2
Issues in the Design and
Implementation of the Concurrent
Object-Oriented Language Hybrid
Hybrid is a concurrent object-oriented language and runtime system that was developed at the
University of Geneva. The aim of the project was to integrate the basic object-oriented concepts
of encapsulation, data abstraction and inheritance with strong typing, concurrency, persistence
and distributed execution. The integration of all these features in a single system was innovative
as, to our knowledge, there was no other language/system which had achieved a similar goal,
and still the clean integration of some of these features remains an open problem. The original
language design was presented in [62] and the design and implementation of a prototype, includ-
ing a substantial subset of the projected features, is described in [42].
The implementation of the prototype uncovered difficulties in the integration of several
features as well as semantic flaws in the original language design[62][63]. Thus, the language
has undergone some changes in order to patch these flaws, and some features, whose integration
deserved more examination, were left out to make the implementation easier. The examples and
further discussion on Hybrid, unless explicitly stated, are about the implemented language pro-
totype [42].
The experience that was gained through the development of the prototype and the further
study of the design of Hybrid by us [68] as well as by other researchers [41][80] brought out
several issues concerning the integration of object-oriented concepts with other features and
concurrency in particular.
Overview of Hybrid
22
In this chapter, using Hybrid as a concrete example, we discuss several issues concerning
the design and implementation of concurrent object-oriented languages. We start with a short
overview of the Hybrid language that provides the necessary background for understanding the
issues discussed in later sections. Then we present the concurrency features and their implemen-
tation and discuss their integration with object-oriented features. We conclude by summarizing
the general issues in the design of COOPLs, revealed through our experience with Hybrid, con-
cerning the successful application of object-oriented techniques for the construction of concur-
rent software.
2.1 Overview of Hybrid
Hybrid is a strongly typed language which, by abstract typing, subtyping and dynamic binding,
combines most of the advantages of static (compile time) type checking with the flexibility of
non statically typed languages as Smalltalk[34].
Object Types
The language constructs for type definition include a number of predefined object types such as
integers and booleans, more conventional type constructors such as structures and enumerated
types, and an
abstract
construct that supports the definition of abstract data types. The use of the
abstract type constructor is shown below in the definition of a stack of integers.
type integerStack:
abstract{
push: integer ->;
pop: -> integer;
empty: -> Boolean;
full: -> Boolean;
}
private{
instance variables
var buffer: array[1..100] of integer;
var top:= 0: integer;
implementation of the operations
empty(): -> Boolean;
{ return( top =? 0); }
full(): -> Boolean;
{ return( top =? 100); }
...more operation implementations ...
}
Chapter 2 23
All objects are typed. We distinguish between the effective and actual type of objects. The
effective type determines the operations that are supported and that determine the objectÕs inter-
face. The actual type of an object determines the representation of its internal state and the im-
plementation of its operations.
Type equivalence is defined as structural equivalence[2] on the effective object types. Two
types are equivalent if their instances support the same number of operations which have the
same names and number of arguments, and the types of arguments and return types are equiva-
lent. Predefined types such as integer and character, provide the base case in this recursive def-
inition. A conformance relation on types is defined as follows: A type S conforms to a type T if
for every operation supported by T,S supports an operation with the same name and the types
of arguments and return values are of equivalent types.
Type checking is based on the conformance relation over the effective types of objects and
determines, at compile time, whether the types of expressions conform to the type required by
the context where they appear. This ensures that the invoked operations are effectively defined
at the interface of invoked objects.
This approach to typing and conformance accounts for polymorphism [20] in the Hybrid
type system and supports the construction of programs which operate on refined versions of con-
forming types yet to be defined. It is important to note that unlike other typed object-oriented
languages, such as C++ [76] and Eiffel [54] where conformance requires that an inheritance link
exists between conforming types, the typing issues are kept separate from inheritance as in
POOL-I[7].
Hybrid also supports the definition of parametrized types and provides the possibility to
constrain the type parameters to be equivalent or conform to some existing type.
Object Interaction and Concurrency
Objects in Hybrid are active entities that interact by invoking one anotherÕs operations in a re-
mote procedure call fashion. An object sends a call message to another, requesting it to execute
one of its methods, and then waits until the results are returned by a return message. Arguments
to operation invocations are passed by value. This decision was made in order to support distrib-
uted execution and to provide more control on the use of an objectÕs subobjects (objects stored
in its instance variables) by not allowing them to be referenced by other objects. Object sharing
and a form of argument passing by ÒreferenceÓ is supported by explicit use ofoids which are
objects holding references to other objects.
Overview of Hybrid
24
The thread of nested remote procedure calls amongst a set of objects is called an activity.
An activity is created by invoking an operation defined as a reflex.The invocation of a reflex
takes place by sending a start message after which the sender proceeds in parallel with the re-
ceiver.
A collection of objects consisting of a Òtop-levelÓ object and its subobjects is called ado-
main. When an object is created it is possible to specify whether the new object is in the domain
of its creator or if it is created as an independent top-level object. A domain is the unit of paral-
lelism and it may be in one of the three states:active,blocked or idle. It is active when an object
is executing an operation in response to a call or start message. It is blocked when it has invoked
the operation of another object and waits for the reply. It is idle if it is neither active nor blocked.
An object in a idle domain may accept any kind of message
1
from any activity. Objects in
a blocked domain may accept return as well as call messages associated with the corresponding
activity. The possibility of accepting further call messages associated with the activity on which
the domain is blocked supports a form of ÒrecursiveÓ call allowing an object to call itself or its
caller without causing a deadlock.
Apart from the above rules, acceptance of call messages may be controlled in a program-
mer-defined way by the delay queue mechanism. Delay queues are defined as instance variables
of type delay. They may be open or closed and may be associated with the operations of the ob-
ject. The acceptance of call messages for an operation associated with a closed delay queue is
delayed until the delay queue is open.
The delegated call mechanism, explained shortly, allows an object to call an other object
without becoming blocked. A delegated call causes the domain of the calling object to become
idle. Thus, the caller or other objects in the domain may switch their attention to other activities.
This feature is made possible by supporting multiple threads within objects which execute in a
quasi-concurrent fashion.
The synchronization provided by domains and activities is very useful for computations in-
volving the coordinated execution of a collection of objects. The correctness of such a compu-
tation is based on implicit assertions on the states of participating objects. The concurrent exe-
cution of objects may cause state changes that invalidate such assertions. Domains and activities
provide the possibility to coordinate the execution of objects so that no interference may occur
by their concurrent execution.
1. it is possible for an idle object to receive a return message because of the delegated call mechanism ex-
plained next.
Chapter 2 25
For example, a bank account class,
Account
, supports, among others, operations for reading
its balance, and withdrawing and depositing an amount. A
Teller
class is used to provide restrict-
ed access to bank account operations. This class supports operations for reading an accountÕs
balance and withdrawing an amount under a certain limit. When a withdrawal is requested to an
instance of this class it checks that the requested amount does not exceed this fixed limit and that
sufficient funds are available in the associated bank account. It then carries out the withdrawal
by invoking the bank accountÕs withdraw operation.
If
Teller
instances and their associated accounts are independent objects the concurrent ex-
ecution of teller objects sharing an account may interfere causing the account to be overdrawn.
This situation is illustrated in figure 2.1-1 where two
Teller
instances and a shared account are
shown as independent objects. The concurrent execution of requests by teller objects may take
place as follows: Both teller objects accept withdrawal requests at (1), (2) for amounts not ex-
ceeding the fixed limit. Then both check at (1.1) and (2.1) whether the requested amount does
not exceed the accountÕs balance and then proceed with the withdrawal at (1.2) and (2.2). How-
ever, if the sum of the requested amounts exceeded the accountÕs balance the account would be
overdrawn.
This problem, as other such problems, may be solved by having the
Teller
instances and the
associated account be in the same domain. As illustrated in figure 2.1-2, once a withdrawal re-
quest is accepted by one object, say Teller1, requests from other activities are delayed at the do-
(1.1)
(2.1)
(1.2)
Account
Teller1
Teller2
1
call message
completed rpc
object boundary
domain boundary
Withdraw1
Withdraw2
(2.2)
(1.1)
(1.2)
Teller1
2
Withdraw1
Withdraw2
Account
Teller2
(1)
(2)
Figure 2.1
The Concurrency Features
26
main boundary. This is an elegant solution to this problem which allows the different access
views to accounts to be represented as separate objects classes. Moreover, no extra programming
effort is required in the implementation of the
Teller
and
Account
classes for synchronizing the
execution of their instances.
2.2 The Concurrency Features
Hybrid includes high level constructs that directly support object interactions according to the
message passing model that was presented in the previous section. As remote procedure calls are
the primary means for expressing object interaction, the language classifies as an operation ori-
ented language in the concurrent programming language classification of Andrews and Schnei-
der [9].
In order to motivate the presentation of the concurrency constructs of Hybrid we are going
to use the concurrency requirements of Liskov et al.[49] for the construction of distributed pro-
grams. These programs are considered to be structured as a collection of active modules acting
as servers and clients, a structure that closely matches object-oriented programs.
The main requirement formulated in [49] is that when an activity becomes blocked within
a module (object in the case of Hybrid) other activities should be able to proceed. They identify
two common situations where an activity may get blocked:local delay and remote delay.
Local delay is the situation where an object is unable to service a request because of the
temporary unavailability of a local resource. In such a case, the object should be able to set aside
this request and turn its attention to others. Moreover, not being able to set aside a request that
cannot be processed immediately may also cause unnecessary deadlocks; while being blocked
because of the unavailability of a local resource, the object would be unable to accept requests
that would made the resource available. For instance, a full bounded buffer object should be able
to accept requests for removing items in order to get to a state where further requests to insert
items can be processed.
Remote delay is the situation in which an activity is delayed within an object because of a
call to another object acting as a Òlower levelÓ server. The delay may be due to the communica-
tion delay, the time needed by the lower level server for handling the request or a local delay in
the lower level server. During this time further requests could be accepted and processed by the
object.
Chapter 2 27
2.2.1 Local Delays With Delay Queues
In Hybrid, simple forms of local delay are handled easily with delay queues. The use of delay
queues allows objects to avoid accepting a request that would lead to a local delay. An illustra-
tion of the use of delay queues for simple cases of local delays is given below by the code outline
of a bounded buffer.
type boundedBuffer : abstract {
init : ->;
put : string ->; uses delay;
get : -> string; uses delay;
};
private {
var putDelay, getDelay: delay;
var buffer: strarray;
...
init: ->;
{
...putDelay.open();
getDelay.close();
}
get: -> string; uses getDelay;
{
...get an item.
if the buffer is now empty
getDelay.close();
putDelay.open();...
}
put: string ->; uses putDelay;
{
...insert an item
if the buffer is now full
putDelay.close();
getDelay.open();
}
}
The delay queues
getDelay
and
putDelay
are used for avoiding the acceptance of
get
and
put
requests when the buffer is empty and full respectively. Initially the delay queue
getDelay
is
closed so that no
get
requests are accepted and the delay
putDelay
is open so that
put
requests are
accepted and items may be inserted in the buffer. When the method
put
is executed it opens the
delay queue
getDelay
so that
get
requests may be accepted. The method g
et
determines whether
the buffer is empty and then closes the
getDelay
delay queue. The method
put
closes the
putDelay
delay queue when the buffer is full.
The Concurrency Features
28
In the above example, whether a request will lead to a local delay is determined by the re-
quested method and the local state of the object. However, there are cases where this information
is not sufficient and it is also necessary to know the values of the methodÕs arguments[15]. Such
cases are dealt with in Hybrid by combining delay queues with the delegated call mechanism. In
section 2.2.3, after we have introduced the delegated call mechanism, we will show how to han-
dle more complex cases by a combination of delay queues and delegated calls.
2.2.2 Remote Delays With Delegated Calls
The delegated call mechanism is well suited for remote delays. When an object issues a delegat-
ed call the executing thread is suspended. Another request may then be processed by another
thread. A thread that was suspended because of a delegated call is resumed after the delegated
call returns and there are no other active threads within the object.
As an example illustrating the use of the delegated call mechanism, consider an object that
operates as an administrator for a collection of worker objects. This object is acquainted with a
collection of worker objects that it uses for servicing the requests made by clients. Remote de-
lays occur when the administrator invokes a particular worker for doing the job. It would not
make sense for the administrator to wait until the worker finishes the requested work. Instead, it
should accept other requests and pass them on to other workers that would process them in par-
allel. The use of the delegated call mechanism allows the administrator to switch its attention to
another request while a call is passed on to a worker. The outline of the administrator is given
below.
type administrator: abstract {
doWork(work: WorkType)-> resultType;
} ;
private{
var workers: array[1..MAX] of oid of workerType;
doWork(work: WorkType) -> resultType
{
var workerIndex: integer;
var result : resultType;
select the worker appropriate for this work,
assign its index to workerIndex.
Pass on the request to the worker by issuing a delegated call
result <- delegate(@workers[workerIndex].doIt(work));
gather some statistics about workers based on result
return the result to the caller.
Chapter 2 29
return(result);
}
}
The
delegate(...)
expression causes the executing thread to be suspended and the call mes-
sage to be passed on to the selected worker. While the worker handles the call, another call may
be accepted by the administrator. This call is handled by the implicit creation of a new thread.
However, there may not be more than one active thread at a time within an object. Suspended
threads are resumed after the delegated call has returned and there are no other active threads
within the object.
2.2.3 Using Delegated Calls and Delay Queues for Local Delays
In section 2.2.1 we mentioned that some local delays that cannot be handled by delay queues
alone can be handled by combining delay queues and delegated calls.
In order to suspend the execution of one of its methods, an object may issue a delegated call
to another object. The delegated call causes the invoking thread to be suspended and the object
is free to accept further requests. If the method invoked by the delegated call is associated with
a closed delay queue, the suspended thread in the calling object is delayed until the execution of
another method opens the delay queue. This causes the call to be accepted so that the delegated
call may return.
A typical object, used for suspending the execution of another objectÕs methods, would pro-
vide two methods:
suspend
and
resume
implemented as follows:
private{
var suspendDelay: Delay;
This delay is initially closed so that callers are delayed
suspend():->; uses suspendDelay;
{
Close the delay so that the next caller will be suspended
suspendDelay.close();
}
resume(): ->;
{
suspendDelay.open();
}
}
The delay queue
suspendDelay
is initially closed. An object willing to suspend the execu-
tion of one of its methods issues a delegated call of the form:
delegate(@secondObject.suspend())
.
An Implementation of The Hybrid Concurrency Model
30
This suspends the calling activity until a call to
resume
opens the delay queue. As
suspend
is
called by a delegated call the calling object is free to accept further calls before the call to sus-
pend returns. A call to
resume
opens the delay queue and so that the call to
suspend
may be pro-
cessed and the invoking thread resumed. The resumed thread closes the delay queue so that the
next call to
suspend
will also be delayed. This example assumes that
resume
is called only when
there is a delayed call. If not, the delay queue would remain open and the next call to
suspend
would not be delayed.
2.3 An Implementation of The Hybrid Concurrency Model
For the implementation of the Hybrid prototype [42] we developed,on top of Unix, a runtime
environment to better support the needs of the system. This runtime environment which provides
support for concurrency, persistence and communication with the outside world is implemented
as a single Unix process. Concurrency is supported by a Òcustom madeÓ package for lightweight
processes which share the address space of this Unix process. Persistence is provided as in the
Smalltalk-80 system by saving the workspace of active objects to a file. The size of the work-
space is limited to the size of virtual memory. Communication to the outside world is provided
by an i/o package based on Unix sockets. This i/o package is integrated with the lightweight
package in the sense that i/o requests block only the requesting lightweight process and multiple
ÒvirtualÓ connections are supported over a single socket.
Figure 2.2 shows the systemÕs architecture. The basic system components are the work-
space manager, the type manager and the activity-domain manager. The workspace manager
maintains a persistent workspace for storing objects. The type manager maintains information
about object types. The activity-domain manager keeps track of the state of execution of Hybrid