Language Abstractions for Controlling Shared Mutable State in Actor Systems

193 Pages·2015·1.05 MB·English

by  Joeri De Koster

Faculty of Sciences and Bio-Engineering Sciences
Department of Computer Science
Software Languages Lab
Domains: Language Abstractions for Controlling Shared
Mutable State in Actor Systems
Dissertation Submitted for the Degree of Doctor of Philosophy in Sciences
Joeri De Koster
Promotors: Prof. Dr. Theo D’Hondt
Dr. Tom Van Cutsem
January 2015
© 2015 Joeri De Koster
Printed by
Crazy Copy Center Productions
VUB Pleinlaan 2, 1050 Brussel
Tel / Fax : [phone]
[e-mail]
www.crazycopy.be
ISBN 978 90 8224 807 4
NUR 989
Alle Rechten voorbehouden. Niets van deze uitgave mag worden vermenigvul-
digd en/of openbaar gemaakt worden door middel van druk, fotokopie, micro-
film, electronisch of op welke andere wijze ook, zonder voorafgaande schrifte-
lijke toestemming van de auteur.
All rights reserved. No parts of this book may be reproduced in any form by
print, photoprint, microfilm, electronic or any other means without prior writ-
ten permission from the author.
ABSTRACT
Traditionally,concurrencymodelsfallintotwobroadcategories:flexibleversus
safe and manageable concurrency control. On one end of the spectrum there
areshared-memorymodelssuchasthreadsandlockswhichareveryflexiblebut
offeralmostnosafetyguarantees.Ontheotherendofthespectrumareisolated
message-passing models which are often more stringent, favoring safety and
liveness guarantees.
The actor model is such a message-passing concurrency model and because
of the asynchrony of its communication mechanism and isolation of its diffe-
rent processes the actor model avoids issues such as deadlocks and low-level
data races by construction. This facilitates concurrent programming, especially
in the context of complex interactive applications where modularity, security
andfault-tolerancearerequired.Thetrade-offisthattheactormodelsacrifices
expressiveness with respect to parallel access to shared state.
Thisdissertationaimstoshowthatstrictisolationisnotaprerequisitetogua-
ranteedeadlockandraceconditionfreedom,andthatbreakingwithno-shared-
state concurrency can improve the flexibility of message-passing concurrency
models while still maintaining their safety guarantees.
In this dissertation, we give an overview of the issues that come with repre-
senting shared resources in modern actor systems and then formulate an ex-
tension to the actor model that allows safe and expressive sharing of mutable
stateamongotherwiseisolatedconcurrentcomponents.Weproposedomainsas
a set of novel language abstractions for encapsulating and sharing state. With
the domain model, we introduce four types of domains, namely immutable,
isolated, observable and shared domains. The design and implementation of
the domain model is realized in the context of SHACL, a novel communicating
event-loopactorlanguage.Wevalidatetheusefulnessofourmodelbyapplying
it in practice through a case study in Scala.
i

SAMENVATTING
Traditioneel kunnen concurrency modellen opgedeeld worden in twee catego-
rieën: flexibele versus veilig en beheersbare concurrencycontrol. Aan het ene
uiteinde van het spectrum er zijn gedeeld-geheugen modellen zoals threads en
locksdiezeerflexibelzijnmaarbijnageenveiligheidsgarantiesbieden.Aanhet
andere uiteinde van het spectrum zijn geïsoleerde message-passing modellen
die vaak strikter zijn, ten voordele van de veiligheidsgaranties van het resulte-
rende model.
Het actormodel is zo een message-passing model en omdat het actormodel
asynchrone communicatie hanteert en de verschillende processen strikt geïso-
leerd zijn vermijdt dit model gekende concurrencyproblemen zoals deadlocks
enelementairedataraces.Ditvergemakkelijktconcurrentprogrammeren,voor-
namelijk in de context van complexe interactieve applicaties waarbij eigen-
schappen zoals modulariteit, veiligheid en fouttolerantie belangrijk zijn. De
keerzijde van de medaille is dat dit model aan expressiviteit opoffert betref-
fende parallelle toegang tot gedeelde informatie.
Deze verhandeling stelt zich tot doel aan te tonen dat strikte isolatie van de
verschillendeactorengeenvereisteisomdeadlocksendataracestevermijden.
De breuk maken met no-shared-state parallelisme kan de flexibiliteit van het
message-passing concurrency modellen verbeteren en tegelijkertijd hun veilig-
heidsgaranties bewaren.
In deze verhandeling starten we met een overzicht van de verschillende pro-
blemen die zich voordoen bij het voorstellen van gedeelde informatie in mo-
derne actorsystemen. Nadien formuleren we een uitbreiding van het actormo-
del dat de programmeur in staat moet stellen om op een veilige en expressieve
manier gedeelde informatie voor te stellen. We stellen domeinen voor als een
set van verschillende taalabstracties voor het inkapselen en delen van informa-
tie. Met dit model stellen we vier verschillende types van domeinen voor, met
name niet-aanpasbare, geïsoleerde, observeerbare en gedeelde domeinen. Het
ontwerpendeimplementatievandomeinenzijngerealiseerdindecontextvan
SHACL, een nieuwe communicating event-loop actor programmeertaal. We va-
lideren ook de bruikbaarheid van ons model door het toe te passen in de prak-
tijk door middel van een case study in Scala.
iii

ACKNOWLEDGEMENTS
Throughout my Phd I have been lucky enough to receive the support of not
one, but two outstanding promotors. I would like to thank Prof. Theo D’Hondt
for being largely responsible for shaping my views on programming language
design and implementation. Every building needs a strong foundation and the
work I did during my Phd is largely founded upon his principles. I would also
like to thank Dr. Tom Van Cutsem for helping me put together the ideas pre-
sented in this dissertation. His involvement in my work truly marked the start
of my Phd and many of the ideas and concepts introduced in this work derive
from the discussions we had together. I cannot thank him enough for sticking
around to see it through until the end.
I would also like to thank Dr. Stefan Marr, my favourite German I love to
hate.Thankyouforgivingmethenecessarywhippingfromtimetotime,those
always led to peaks in my productivity and tremendously helped in getting
some of my work published. I loved you as a fellow researcher and as an office
mate and was sad to see you go.
Abigthanksgoesouttothemembersofmyjury:Prof.PhilippHaller,Dr.Roel
Wuyts, Prof. Wolfgang De Meuter, Prof. Jennifer Sartor, Prof. Philippe Cara, Dr.
Yann-Michaël De Hauwere. Thanks for critically reading my dissertation and
helping in improving the quality of this text.
I would like to thank all the (former) members of the Software Languages
Labforprovidinganexcellentenvironmenttoworkin.Specialthanksgoesout
totheParallelProgrammingPeopleforalltheinsightfuldebatesandiscussions
during our meetings.
I would also like to thank my family and friends to take my mind off “dinges
met computers” and do some more fun stuff from time to time.
Last,but notleast, Iwould liketo thankFlorence Dusart,mybest friend,life
partner,wifeandmotherofmychild.WemetwhenIstartedstudyingComputer
Scienceandshehassincesupportedmethroughmyentireacademiccareer.All
of the important choices I made in life, including doing the Phd of which this
workistheendresult,Imadetogetherwithher.Iamthereforedeeplyindebted
to her.
This work is funded by a Phd scholarship of the Institute for the Promotion
of Innovation through Science and Technology in Flanders (IWT).
v

INHOUDSOPGAVE
1. Introduction 1
1.1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Research Vision . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Supporting Publications and Technical Contributions . . . . . . . 6
1.5. Dissertation Outline . . . . . . . . . . . . . . . . . . . . . . . . . 8
2. Context: Actor Systems 11
2.1. The History of Actor Systems . . . . . . . . . . . . . . . . . . . . 12
2.1.1. Agha’s Actor Model: ACT, SAL and Rosette . . . . . . . . . 13
2.1.2. ABCL/1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.1.3. Erlang . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.4. SALSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.5. Asynchronous Sequential Processes and ProActive . . . . . 18
2.1.6. E Programming Language . . . . . . . . . . . . . . . . . . 19
2.1.7. Scala Actor Library and Akka . . . . . . . . . . . . . . . . 21
2.1.8. Kilim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.2. Actor System Classification and Properties . . . . . . . . . . . . . 24
2.2.1. Classification of Actor Systems . . . . . . . . . . . . . . . 24
2.2.1.1. Original Actor Model . . . . . . . . . . . . . . . 24
2.2.1.2. Processes . . . . . . . . . . . . . . . . . . . . . . 24
2.2.1.3. Active Objects . . . . . . . . . . . . . . . . . . . 25
2.2.1.4. Communicating Event-Loops . . . . . . . . . . . 26
2.2.2. Actor Properties . . . . . . . . . . . . . . . . . . . . . . . 26
2.2.2.1. Message Processing . . . . . . . . . . . . . . . . 26
2.2.2.2. Message Reception . . . . . . . . . . . . . . . . . 28
2.2.2.3. State Changes . . . . . . . . . . . . . . . . . . . 29
2.2.2.4. Actors Per Node . . . . . . . . . . . . . . . . . . 30
2.3. The Isolated Turn Principle . . . . . . . . . . . . . . . . . . . . . 30
vii
Inhoudsopgave
2.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3. Shared State in Modern Actor Systems 33
3.1. Shared State in Pure Actor Systems . . . . . . . . . . . . . . . . . 34
3.1.1. Replication . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.1.2. Delegate Actor . . . . . . . . . . . . . . . . . . . . . . . . 35
3.1.2.1. Code Fragmentation and Continuation-passing
Style Enforced . . . . . . . . . . . . . . . . . . . 36
3.1.2.2. No Parallel Reads . . . . . . . . . . . . . . . . . 38
3.1.2.3. Message-level Race Conditions . . . . . . . . . . 38
3.1.2.4. Message-level Deadlocks . . . . . . . . . . . . . 40
3.1.2.5. Conclusion . . . . . . . . . . . . . . . . . . . . . 40
3.2. Shared State in Impure Actor Systems . . . . . . . . . . . . . . . 40
3.2.1. Locks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.2.2. Software Transactional Memory . . . . . . . . . . . . . . . 42
3.3. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4. Communicating Event-Loops 45
4.1. Why Communicating Event-Loops? . . . . . . . . . . . . . . . . . 46
4.1.1. Fine-grained versus Coarse-grained Concurrency . . . . . 46
4.1.2. Flexible versus Fixed Behavior. . . . . . . . . . . . . . . . 46
4.2. SHACL: A Communicating Event-Loop Language . . . . . . . . . 48
4.2.1. Imperative Programming in SHACL . . . . . . . . . . . . . 48
4.2.2. Object Oriented Programming in SHACL . . . . . . . . . . 51
4.2.3. Actor Oriented Programming in SHACL . . . . . . . . . . 52
4.3. Shared State in SHACL, A Motivating Example . . . . . . . . . . 57
4.3.1. An Idealized Implementation of the Motivating Example . 59
4.4. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5. The Domain Model 61
5.1. The Design Space: Event-loops × Object Heaps . . . . . . . . . . 62
5.2. Domains: Immutable, Isolated, Observable, Shared . . . . . . . . 63
5.3. SHACL: A Language with Domains . . . . . . . . . . . . . . . . . 63
5.4. Immutable Domains . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.5. Isolated Domains . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.6. Observable Domains . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6.1. Observable Actors . . . . . . . . . . . . . . . . . . . . . . 70
5.6.2. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.6.3. A Note on the Implementation . . . . . . . . . . . . . . . 71
viii