a reflective approach to actor-based concurrent context-oriented systems
TRANSCRIPT
A Reflective Approach to Actor-Based Concurrent Context-Oriented Systems
Takuo WATANABE & Souhei TAKENOTokyo Institute of Technology
1
About This Work
• Proposes a reflective solution to a problem regarding context-crossing messages (CCMs) in actor-based context-oriented systems
Asynchronous Context Changing
• Talk outline- COP in Actor-Based Systems- Context-Crossing Messages- Solutions using Group-Wide Reflection- Future Work
2
The Actor Model (1)
A concurrent computation model based on asynchronous message passing
- Originally invented by C. Hewitt in 1970s and developed by G. Agha and other researchers in 1980-90s.
- Today:Erlang, Scala, Akka, libcppa, etc.
• In the Actor model, a system is modeled as a collection of actors that communicate with each other only via asynchronous messages.- "Shared Nothing": no shared states, no global clock
3
actormessage
The Actor Model (2)
• On receiving a message, an actor may- send messages to other
actors (or itself),- create new actors, and- change its internal state (behavior).• Message arrival is guaranteed
- Delay is unbounded• Each actor has a mail queue (mailbox) to buffer
incoming messages.
4
COP in Actor-Based Systems
• An application is constructed as a group of actors.• A special actor called observer continuously observes
the application context.• Upon detecting a change of the context, the observer
broadcasts context-changing messages to application actors.
5
observer
context changing messages
application actors
O
A
B
old context new context
Application Messages and Context
• In (a) and (b), application messages cross the context-borders (red lines).
6
O
A
B
O
A
B
O
A
B
O
A
B(a) (b)
(c) (d)
Context-Crossing Message (CCM)
• An application message that crosses context-borders• It is sometimes problematic, for example, if the
message brings a context-dependent data structure.• Two kinds of CCMs:
• "New-to-old" CCMs can be resolved by piggybacking context information with application messages• No such local solution for "old-to-new" CCMs!
7
O
A
B
O
A
B(a) old-to-new (b) new-to-old
change by piggybacked context info.
Ex: Mobile Device
• The device is a shared-memory multicore machine.• An application is constructed as a group of fine-
grained actors and they communicate via messages that may contain context-dependent data structures.• CCMs occur even if a shared variable is used to
express context.
8
WO
A
B
O
A
B(a) old-to-new (b) new-to-old
R
R
W
R
R
Ex: Context-Oriented Sensor Network
• A message contains:- "Average" context: (sum, count)- "Maximum" context: (maximum, node#)
9
+
+
+
+
+
+
+
max
max
max
max
max
max
max
maximum of the measured values
average of the measured values
“Average” context “Maximum” context
sensor node actor
Related Work
• ContextErlang [Salvaneschi et al. '12]- prohibits in-method context-changing- does not provide solutions to CCMs• Synchronization Mechanisms for Actors
- Synchronizers [Frølund '96]- Directors [Varela et al. '99]- ARC [Ren et al. '06]- Domains [De Koster et al. '12]
10
Contribution
• Optimistic and pessimistic solutions using Group-Wide Reflection (GWR)- Parallel actor composition is used to construct meta-level
actor groups [Watanabe, 2013]• Strictly synchronized context changing (= no CCMs)
realized by a customized meta-level actors
11
Group-Wide Reflective Architecture
12
Watanabe'&'Yonezawa,'REX/FOOL''90'(LNCS'#489)�
a'grou
p'of'ob
jects�
The$collec(ve$behavior$of$a$group$of$concurrent$objects$is$represented$as$a$coordinated$ac(ons$of$a$group$of$meta8objects$(meta8group).�
The$default$behavior$of$meta8group$is$proved$to$simulate$the$behavior$of$base8level$objects.�
Reflec(ve$behaviors$are$realized$by$inter8level$messages.�
Applica(ons:$$Dynamic$Object$Migra(on,$Adap(ve$Scheduling,$etc.�
metaIgro
up�
metaIobjects:'shared'execuNon'engine,'message'router,'etc.�
Parallel Composition of Actors (1)
• Compose the member in an actor group into a single actor that exhibits the same behavior as the original group.
13
Parallel Composition of Actors (2)
A1 = 〈〈1, m〉, q1, e1, s1〉
A2 = 〈〈2, m〉, q2, e2, s2〉
〈〈1, m〉, k1〉
〈〈2, m〉, k2〉
A1+A2 = 〈m, q, e, s〉
〈〈1, m〉, k1〉 ↦ 〈〈m, (1, k1)〉
〈〈2, m〉, k2〉 ↦ 〈〈m, (2, k2)〉
14
letrec fib ={ (0, c) → [c ⇐ 0]; become fib| (1, c) → [c ⇐ 1]; become fib| (n, c) where n > 1 →
let nc = new(λx.become(λy.[c ⇐ x + y]))in [self ⇐ (n - 1, nc)];
[self ⇐ (n - 2, nc)];become fib
}
Figure 4: A Behavior Function for Fibonacci Actors
a1(2, a1)
(1, (2, a1))
(2, (2, a1)) (3, a1)
a2
(1, a1)a3
(1, a3)
actor
groupboundary
ai baseaddress
Figure 5: Actor Groups
become e replaces the behavior function of the actor evalu-ating this expression with a function to which e evalu-ates. The new behavior function will be applied to thenext incoming message.
self evaluates to the address of the actor evaluating thisexpression.
Other expressions such as tuples, sequencing, conditional,match, let and letrec can be encoded with basic expressionsas usual. Case functions and pattern argument functions areexpressed as
{ cls } ≡ λx.match x with cls end (x ̸∈ FV(cls))
λp.e ≡ { p → e }
where FV(cls) denotes the set of variables occurring freelyin cls.In addition, we use some“built-in”constants and functions
such as the unit value, boolean values, numbers, strings,symbols, arithmetic functions, equality functions and so on.Some of these functions are used in infix notation.Figure 4 shows an example of a behavior function for ac-
tors that compute Fibonacci numbers recursively. Note thatletrec without body is used to define “toplevel” names. Wecan obtain an instance (actor) by evaluating the expres-sion new fib. The created actor receives a message thatis a pair (n, c) of an integer and an actor that receivesthe result of the computation. For example, by evaluating[new fib ⇐ (10, printer)], the actor printer will receivethe result (55).
2.2 Actor Groups and Group AddressesIn our language, an address is either a single atomic value
or a pair of an index (a positive integer) and an address.The former is called a base address and the latter is calleda composite address. This hierarchical address structure isused for organizing actor groups.Let a be a composite address and a = (i, a′). We call the
components i and a′ the local index and group address ofa respectively. An actor group is a collection of actors that
share a common group address. For example, in Figure 5,we have six actors with the addresses (1, a1), (1, (2, a1)),(2, (2, a1)), (3, a1), a2 and (1, a3) where a1, a2, a2 are baseaddresses. The actors with addresses (1, a1) and (3, a1) be-long to the group with the address a1, and the actors withaddresses (1, (2, a1)) and (2, (2, a1)) belong to the group withthe address (2, a1). The group (2, a1) itself belongs to thegroup a1 and is called a subgroup of a1. The actor a2 doesnot belong to any group and the actor (1, a3) is the solemember of group a3.
Note that if an address is used as the group address ofan actor or a group, no actor with the address is allowed toexist. For example, addresses a1, a3 and (2, a1) in the aboveexample cannot be the addresses of actors.
Suppose that a is the address of an actor. Usually, theactor receives messages whose destination address is a. Inaddition to such normal message delivery, our language of-fers a routing mechanism that redirects a message whosedestination address is (i, a) to the address a. The actor withthe address a will receive a message (i,m) where m is theoriginal message content. Similarly, when a message withcontent m is sent to the address (i2, (i1, a)), the actor withaddress a will receive a message with content (i1, (i2,m)).
2.3 Compositional Meta-Level Actors
2.3.1 Actor CompositionOur language offers a simple group-wide reflection mech-
anism based on compositional meta-level actors. This sub-section presents the overview of the actor composition usedto construct meta-level actors.
We give an intuitive explanation of the composition usinga simple example. Let a be the address of a group thatas two member actors with addresses (1, a) and (2, a). Theinitial behavior functions of the actors, named A1 and A2
respectively, are defined as follows.
let A1 = { p1 → e1; become A′1 }
let A2 = { p2 → e2; become A′2 }
Note that e1 and e2 do not contain become expressions.By composing A1 and A2, we obtain the behavior function
A1+A2 defined as follows.
let A1+A2 ={ (1, p1) → e1; become A′
1+A2
| (2, p2) → e2; become A1+A′2 }
The behavior functions A’+B and A+B’ should also be de-fined in similar way.
By using this definition, we can replace the entire group(whose members are actors with addresses (1, a) and (2, a))with a single actor with address a that has A1+A2 as theinitial behavior function. Thanks to the message routingmechanism described in the previous subsection, messagesthat are sent to the addresses (1, a) or (2, a) will be deliveredto the composed (replacement) actor. The composed actorbehaves as if it were either of the group member actors.
2.3.2 Meta-Level ActorsThe reflection capability in our language is based on a per-
actor meta-level architecture that is similar to ABCL/R[16].Thus reflective behaviors are realized by sending messagesto meta-level actors.
letrec fib ={ (0, c) → [c ⇐ 0]; become fib| (1, c) → [c ⇐ 1]; become fib| (n, c) where n > 1 →
let nc = new(λx.become(λy.[c ⇐ x + y]))in [self ⇐ (n - 1, nc)];
[self ⇐ (n - 2, nc)];become fib
}
Figure 4: A Behavior Function for Fibonacci Actors
a1(2, a1)
(1, (2, a1))
(2, (2, a1)) (3, a1)
a2
(1, a1)a3
(1, a3)
actor
groupboundary
ai baseaddress
Figure 5: Actor Groups
become e replaces the behavior function of the actor evalu-ating this expression with a function to which e evalu-ates. The new behavior function will be applied to thenext incoming message.
self evaluates to the address of the actor evaluating thisexpression.
Other expressions such as tuples, sequencing, conditional,match, let and letrec can be encoded with basic expressionsas usual. Case functions and pattern argument functions areexpressed as
{ cls } ≡ λx.match x with cls end (x ̸∈ FV(cls))
λp.e ≡ { p → e }
where FV(cls) denotes the set of variables occurring freelyin cls.In addition, we use some“built-in”constants and functions
such as the unit value, boolean values, numbers, strings,symbols, arithmetic functions, equality functions and so on.Some of these functions are used in infix notation.Figure 4 shows an example of a behavior function for ac-
tors that compute Fibonacci numbers recursively. Note thatletrec without body is used to define “toplevel” names. Wecan obtain an instance (actor) by evaluating the expres-sion new fib. The created actor receives a message thatis a pair (n, c) of an integer and an actor that receivesthe result of the computation. For example, by evaluating[new fib ⇐ (10, printer)], the actor printer will receivethe result (55).
2.2 Actor Groups and Group AddressesIn our language, an address is either a single atomic value
or a pair of an index (a positive integer) and an address.The former is called a base address and the latter is calleda composite address. This hierarchical address structure isused for organizing actor groups.Let a be a composite address and a = (i, a′). We call the
components i and a′ the local index and group address ofa respectively. An actor group is a collection of actors that
share a common group address. For example, in Figure 5,we have six actors with the addresses (1, a1), (1, (2, a1)),(2, (2, a1)), (3, a1), a2 and (1, a3) where a1, a2, a2 are baseaddresses. The actors with addresses (1, a1) and (3, a1) be-long to the group with the address a1, and the actors withaddresses (1, (2, a1)) and (2, (2, a1)) belong to the group withthe address (2, a1). The group (2, a1) itself belongs to thegroup a1 and is called a subgroup of a1. The actor a2 doesnot belong to any group and the actor (1, a3) is the solemember of group a3.
Note that if an address is used as the group address ofan actor or a group, no actor with the address is allowed toexist. For example, addresses a1, a3 and (2, a1) in the aboveexample cannot be the addresses of actors.
Suppose that a is the address of an actor. Usually, theactor receives messages whose destination address is a. Inaddition to such normal message delivery, our language of-fers a routing mechanism that redirects a message whosedestination address is (i, a) to the address a. The actor withthe address a will receive a message (i,m) where m is theoriginal message content. Similarly, when a message withcontent m is sent to the address (i2, (i1, a)), the actor withaddress a will receive a message with content (i1, (i2,m)).
2.3 Compositional Meta-Level Actors
2.3.1 Actor CompositionOur language offers a simple group-wide reflection mech-
anism based on compositional meta-level actors. This sub-section presents the overview of the actor composition usedto construct meta-level actors.
We give an intuitive explanation of the composition usinga simple example. Let a be the address of a group thatas two member actors with addresses (1, a) and (2, a). Theinitial behavior functions of the actors, named A1 and A2
respectively, are defined as follows.
let A1 = { p1 → e1; become A′1 }
let A2 = { p2 → e2; become A′2 }
Note that e1 and e2 do not contain become expressions.By composing A1 and A2, we obtain the behavior function
A1+A2 defined as follows.
let A1+A2 ={ (1, p1) → e1; become A′
1+A2
| (2, p2) → e2; become A1+A′2 }
The behavior functions A’+B and A+B’ should also be de-fined in similar way.
By using this definition, we can replace the entire group(whose members are actors with addresses (1, a) and (2, a))with a single actor with address a that has A1+A2 as theinitial behavior function. Thanks to the message routingmechanism described in the previous subsection, messagesthat are sent to the addresses (1, a) or (2, a) will be deliveredto the composed (replacement) actor. The composed actorbehaves as if it were either of the group member actors.
2.3.2 Meta-Level ActorsThe reflection capability in our language is based on a per-
actor meta-level architecture that is similar to ABCL/R[16].Thus reflective behaviors are realized by sending messagesto meta-level actors.
• By applying the parallel composition to per-actor meta-level definition, we can acquire a group-wide meta-level.• Group-wide operations can be added to the composed
meta-level.
Compositional Construction ofGroup-Wide Meta-level
15
letrec meta1(queue , beh , state , exec1) ={ Mesg v →
if state = Dormant then [self ⇐ Begin];become meta1(queue ++[v], beh , Active , exec1)
| Begin →match queue with| v::queue ’ →
[exec1 ⇐ Apply(beh , v, self )];become meta1(queue ’, beh , state , exec1)
end| End →
match queue with| [] →
become meta1(queue , beh , Dormant , exec1)| _::_ →
[self ⇐ Begin];become meta1(queue , beh , state , exec1)
end}
Figure 6: A Plain Single Meta-Level Behavior
letrec metaG(queue*, beh*, state*, execG) ={ (i, Mesg v) →
if state*[i] = Dormantthen [self ⇐ (i, Begin )];become metaG(queue *{queue*[i] ++ [v]/i},
beh*, state*{ Active/i}, execG)| (i, Begin) →
match queue*[i] with| v::queue ’ →
[execG ⇐ (i, Apply(beh*[i], v, self )];become metaG(queue*{queue ’/i}, beh*,
state*, execG)end
| (i, End) →match queue*[i] with| [] →
become metaG(queue*, beh*,state*{ Dormant/i}, execG)
| _::_ →[self ⇐ (i, Begin )];become metaG(queue*, beh*, state*, execG)
end}
Figure 7: The Composed Meta-Level Behavior
Figure 6 is an example of a default (plain) behavior func-tion for meta-level actors. The argument of the functionmeta1 is a quadruple of the message queue, the behaviorfunction, the state of the base-level and the address of anactor called execution engine.A meta-level actor governs a single base-level actor. As in
ABCL/R, the reception of a message m at the base-level isinterpreted as the reception of the message Mesg m at themeta-level. Then the meta-level actor maintains its mes-sage queue and keeps track of the execution states of thebase-level. The code of the behavior function of the base-level is executed by the execution engine. The execution en-gine starts execution upon receiving a message that matchesApply(...). When the execution finishes, it send End to themeta-level actor.Now let’s define the meta-level actor of an actor group
by composing this behavior description. The behavior func-tion in Figure 6 is carefully defined to avoid combinatorial
explosion of composed behaviors. The trick is that everybecome invocation in the definition uses the same meta-leveldefinition meta1.
Figure 7 shows the result of the composition. To im-plement the behavior of each base-level actor, we need tochange the argument of meta1 to the quadruple of collec-tive (indexed) data structures (e.g., arrays or dictionaries)other than the execution engine. In the rest of the paper, weuse identifiers end with asterisk (such as queue*, beh* andstate*) to denote such collective data structures. We alsouse some built-in operators regarding these data structures.The expression x*[i] denotes the i-th element of x* andx*{v/i} denotes the data structure same as x* except thatits i-th element is replaced by v.
The execution engine can be shared within the group asin [17, 8]. In this example, execG is responsible for theexecution of all members of the group represented by thecomposed meta-level actor. This architecture roughly corre-sponds to queue-based concurrent task management systemssuch as libdispatch1.
3. TOWARDS CONCURRENT COPUsing the composed meta-level actor, we can enjoy vari-
ous sorts of group-wide reflective operations that control thecollective behaviors of an actor groups. This section presentsa possible solution to the synchronization problem describedin the Section 1 using group-wide reflection.
Figure 8 shows the definition of the behavior function ofa composed meta-level actor that can cancel cross-contextmessages within the group governed by this. The meta-levelactor has an extra variable ctx* that keeps the context ofmember actors in the group. In addition, every messagekeeps the context information at its sending time.
A context changing message from the observer looks likeCtx c where c stands for the new context carried by the mes-sage. We assume that contexts are ordered; we write c ≤ c′
if c′ is a newer context than c. When an actor (say X)in the group receives the message with a context changinginformation, the meta-level actor tries to change the con-text of X to the new one. If the current context of X isnewer than the context associated to an incoming message,the meta-level will fix the situation by undoing and redoingthe operations that X has done in the past. The part thathandles messages with constructor Rollback implements thesimple rollback mechanism to keep the system states consis-tent. The algorithm used here is optimistic and is similar tothe TimeWarp algorithm[7].
Figure 9 shows an example execution scenario of the op-timistic algorithm implemented in Figure 8. As in the set-tings in Figure 1, the observer actor O watches the executioncontext and broadcasts context-changing messages to appli-cation actors A and B. In this scenario, the both of the twoapplication messages m and n are CCMs; m is sent in theold context (at p) and is received in the new context (at q),while n is sent in the new context (at u) and is received inthe old context (at v). The latter is easily fixed by a piggy-backing method mentioned in Section 1. In this case, n canbring the context information so that the meta-level actorcan change the context of A (at v) prior to the arrival of thecontext-changing message from O.
The situation regarding the cross-context message m is
1http://libdispatch.macosforge.org
letrec meta1(queue , beh , state , exec1) ={ Mesg v →
if state = Dormant then [self ⇐ Begin];become meta1(queue ++[v], beh , Active , exec1)
| Begin →match queue with| v::queue ’ →
[exec1 ⇐ Apply(beh , v, self )];become meta1(queue ’, beh , state , exec1)
end| End →
match queue with| [] →
become meta1(queue , beh , Dormant , exec1)| _::_ →
[self ⇐ Begin];become meta1(queue , beh , state , exec1)
end}
Figure 6: A Plain Single Meta-Level Behavior
letrec metaG(queue*, beh*, state*, execG) ={ (i, Mesg v) →
if state *[i] = Dormantthen [self ⇐ (i, Begin )];become metaG(queue *{queue*[i] ++ [v]/i},
beh*, state*{ Active/i}, execG)| (i, Begin) →
match queue*[i] with| v::queue ’ →
[execG ⇐ (i, Apply(beh*[i], v, self )];become metaG(queue*{queue ’/i}, beh*,
state*, execG)end
| (i, End) →match queue*[i] with| [] →
become metaG(queue*, beh*,state*{ Dormant/i}, execG)
| _::_ →[self ⇐ (i, Begin )];become metaG(queue*, beh*, state*, execG)
end}
Figure 7: The Composed Meta-Level Behavior
Figure 6 is an example of a default (plain) behavior func-tion for meta-level actors. The argument of the functionmeta1 is a quadruple of the message queue, the behaviorfunction, the state of the base-level and the address of anactor called execution engine.A meta-level actor governs a single base-level actor. As in
ABCL/R, the reception of a message m at the base-level isinterpreted as the reception of the message Mesg m at themeta-level. Then the meta-level actor maintains its mes-sage queue and keeps track of the execution states of thebase-level. The code of the behavior function of the base-level is executed by the execution engine. The execution en-gine starts execution upon receiving a message that matchesApply(...). When the execution finishes, it send End to themeta-level actor.Now let’s define the meta-level actor of an actor group
by composing this behavior description. The behavior func-tion in Figure 6 is carefully defined to avoid combinatorial
explosion of composed behaviors. The trick is that everybecome invocation in the definition uses the same meta-leveldefinition meta1.
Figure 7 shows the result of the composition. To im-plement the behavior of each base-level actor, we need tochange the argument of meta1 to the quadruple of collec-tive (indexed) data structures (e.g., arrays or dictionaries)other than the execution engine. In the rest of the paper, weuse identifiers end with asterisk (such as queue*, beh* andstate*) to denote such collective data structures. We alsouse some built-in operators regarding these data structures.The expression x*[i] denotes the i-th element of x* andx*{v/i} denotes the data structure same as x* except thatits i-th element is replaced by v.
The execution engine can be shared within the group asin [17, 8]. In this example, execG is responsible for theexecution of all members of the group represented by thecomposed meta-level actor. This architecture roughly corre-sponds to queue-based concurrent task management systemssuch as libdispatch1.
3. TOWARDS CONCURRENT COPUsing the composed meta-level actor, we can enjoy vari-
ous sorts of group-wide reflective operations that control thecollective behaviors of an actor groups. This section presentsa possible solution to the synchronization problem describedin the Section 1 using group-wide reflection.
Figure 8 shows the definition of the behavior function ofa composed meta-level actor that can cancel cross-contextmessages within the group governed by this. The meta-levelactor has an extra variable ctx* that keeps the context ofmember actors in the group. In addition, every messagekeeps the context information at its sending time.
A context changing message from the observer looks likeCtx c where c stands for the new context carried by the mes-sage. We assume that contexts are ordered; we write c ≤ c′
if c′ is a newer context than c. When an actor (say X)in the group receives the message with a context changinginformation, the meta-level actor tries to change the con-text of X to the new one. If the current context of X isnewer than the context associated to an incoming message,the meta-level will fix the situation by undoing and redoingthe operations that X has done in the past. The part thathandles messages with constructor Rollback implements thesimple rollback mechanism to keep the system states consis-tent. The algorithm used here is optimistic and is similar tothe TimeWarp algorithm[7].
Figure 9 shows an example execution scenario of the op-timistic algorithm implemented in Figure 8. As in the set-tings in Figure 1, the observer actor O watches the executioncontext and broadcasts context-changing messages to appli-cation actors A and B. In this scenario, the both of the twoapplication messages m and n are CCMs; m is sent in theold context (at p) and is received in the new context (at q),while n is sent in the new context (at u) and is received inthe old context (at v). The latter is easily fixed by a piggy-backing method mentioned in Section 1. In this case, n canbring the context information so that the meta-level actorcan change the context of A (at v) prior to the arrival of thecontext-changing message from O.
The situation regarding the cross-context message m is
1http://libdispatch.macosforge.org
per-actor meta-level
group-wide meta-level
Optimistic Context Synchronization
• Assumptions- single observer- contexts are linearly ordered- each message piggybacks the context of its sender• Algorithm (cf. TimeWarp algorithm [Jefferson '85])
- Each actor should save incoming/outgoing messages and execution states into its history database.
- If an incoming message has a context newer than the current context, update the current context to the new one.
- If an incoming message has an older context• rollback the execution state• re-send incoming messages to itself• send canceling messages of outgoing messages
16
O
A
B
p
q
r
s
t u
v
O
A
B
p
q
r
s
t u
v w s’
q’ t’
u’
v’
m n
m n -n
O
A
B
p
q
r
s
t u
v w s’
q’ t’
u’
v’
O
A
B
p
r
s’
q’ t’
u’
v’
m n -n
Optimistic Context Synchronization in GWR
• Better concurrency- vs. pessimistic approach• Implicit
- Application programmer doesn't need to take care of context synchronization
• Optimization- per-actor basis• Sorting messages in the message queue by context
- group-wide basis• Sorting messages in the combined message queue by
context• Using contexts as scheduling priorities
19
Summary
• Context-crossing messages in concurrent context-oriented systems• A reflective solution to implementing strictly
synchronized context-changing in actor-based systems.
• Future Work• Performance evaluation• Multiple observers• orthogonal contexts / dependency between contexts• Loosely (not-strictly) synchronized contexts• Language (Modularization) mechanism
20