A Reflective Implementation of an Actor-based Concurrent Context-Oriented System

A Reflective Implementation of an Actor-based Concurrent Context-Oriented System

Souhei Takeno & Takuo WatanabeDepartment of Computer Science

Tokyo Institute of Technology

Dec. 8, 2015ARM 2015

1

About This Work

• Introduces a new reflective architecture for actor-based systems, and• Proposes a solution to a synchronization problem in a

concurrent context-oriented programming system

• Talk outline- Actor-Based Group-Wide Reflective Architecture- COP in Actor-Based Systems- Solution to Asynchronous Context Changing- Preliminary Evaluations

2

The Actor Model

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), Io, etc.

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

3

actormessage

Context-Oriented Programming

• A programming paradigm aimed to improve the modularity of context-dependent behaviors- Context• External runtime environment• Internal program state

- Layer• A language mechanism describing code fragments for context-

dependent behaviors• When the runtime system observes the change of its context, it

activate a layer (or a set of layers) that corresponds to the new context.

- COP Languages• Context{J, L, S, JS}, EventCJ, ContextErlang, etc.

4

An Actor-Based COP Model

• 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

Context-Crossing Message (CCM)

• Application messages that cross context-borders are sometimes problematic, for example, if they carry context-dependent information.• 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

6

O

A

B

O

A

B(a) old-to-new (b) new-to-old

change by piggybacked context info.

Ex: Context-Oriented Sensor Network

• Message type: (Double, Int)- "Average" context: (sum, count)- "Maximum" context: (maximum, node id)

7

+

+

+

+

+

+

+

max

max

max

max

max

max

max

maximum of the measured values

average of the measured values

“Average” context “Maximum” context

sensor node actor

Ex: Multicore Mobile Device

• Consider a mobile device equipped with a shared-memory multicore processor• An application is constructed as a group of fine-

grained actors.• "Old-to-new" CCMs may occur even if we use a

shared variable to express context.

8

WO

A

B

R

R

Related Work

• COP in Concurrent Settings- ContextErlang [Salvaneschi et al. '12]• Prohibits in-method context-changing• Does not provide solutions to CCMs

- CoElektra [Raab '15]• Limiting the changes of contexts to synchronization points• Needs explicit specification of synchronization points

• (Global) Synchronization Mechanisms for Actors- Synchronizers [Frølund '96]- Directors [Varela et al. '99]- Transactors [Field et al. '05]- ARC [Ren et al. '06]- Domains [De Koster et al. '12]

9

Contribution

• Optimistic CCOP using Group-Wide Reflection (GWR)- GWR via parallel actor composition [Watanabe, 2013]• Strictly synchronized context changing (= no CCMs)

realized by a customized meta-level actors

• Preliminary Evaluations using Prototypes in Erlang

10

Group-Wide Reflective Architecture

11

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.�

Ad-hoc, Complex Meta-Levels

12

235

Figure 3: The Individual and Group Reflective Towers in ABCL/R2

objects at the meta-level, we maintain the tower of metaobjects in the same manner as the individual- based architecture. For coordinated management of system resources such as computational resource, we introduce object groups, whose meta-level representation is a group of meta-level objects that are responsible for managing the collective behavior of its member objects. The conceptual illustration of the resulting architecture is given in Figure 3. Note that there are two kinds of reflective towers, the individual tower for individual objects and the group tower for groups: the details will be described in the ensuing sections.

The hybrid group architecture does not merely combine the benefits of both architectures; the key benefit is that it is possible to model coordinated resource management which were otherwise difficult for previous OOCR architectures.

3 ABCL/R2: A Hybrid Group Architecture Language ABCL/R2 is our prototype OOCR language with the hybrid group reflective architecture. It is a direct descendent of ABCL/R: each object x has its own meta-object l"x, i.e., the unit of CCSR of an object is its metaobject. Also, as in ABCL/R, (1) the message reception and evaluation may proceed concurrently, preserving the ABCL/1 semantics, and (2) conceptually, there is an infinite structural (object-metaobject relationship) reflective tower per each object; the infinite meta. regression is resolved with lazy creation of the metaobject on demand.

409

., ..... I , - ' S I ! \ Mailer ~t h:task ...] / L _ ! \

t+ / S / % . \ Task I [~'P- III "'i ' " ? ' T -

' I~ "\o i / .~ Evaluator Customers of l" I~ 'It" "". ,, [ ,,. / ^ ~ $ ~ " "" Task Handler I I ~ Z : ' ~ I Behavior ~".t~ 0"~"

[ ~ t'uo-.] --'~ Actors Ix: ~"

Figure 1: Actors in TS

D e f i n i t i o n 1 ( M e t a e o n f i g u r a t i o n ) Let C be a configuration orS. A metaconfiguration TC E Fls of C is defined as a pair (7"(TC),T(TC)):

.A(tc) = {0, ~s, =, ~} u E" u Bs T(TC) = {(u, mo, [ : task tt Tm Tk]) I (t,m,k) C T(C)} where E A = {e* 1" e X(O)}

Bs = { ~ I <m, ~) e x ( c ) }

A task (u, mo, [ : task Tt tm tk]) 6 T(TC) is called a meta-task of (t,m,k) E T(C). It represents a task ( t ,m, k) in the object-level (C). We let Tr denote the recta-task of T. We let u denote the tag of the meta-task, me is the mail address of the task handler actor 0 described below, t t and I'm, called a tag handle and a mail address handle 1 (or handles in short), are the metalevel representations of the tag t and the mail address m. A handle may denote another handle: ~Tm is also valid. Let 7-/be the domain of handles. The functionality of t is:

T:/+M + 7-/-+ ~

Recall that 27 and M are the domain of tags and the domain of mail addresses. We write for the inverse function of T- For any x E 27 + M + 7-/and y 6 7-/, ~l"x = x and T~y = y

holds. Thus T is a bijection, so 7-/should be an (recursive) infinite domain. Handles will be used as keys in the database actor 6 s described below. Tk is the value

which has the same structure as k, but every occurrence of mail addresses and handles in k are replaced with their handles. For example, if k is the value [ :do ma ( foo Tmz)] and ml and m~ are mail addresses, then Tk is [ :do Tin1 ( foo ~Tm2)].

The metalevel actors in .A(TC ) are categorized as follows (see Figure 1). Their precise definition will be given as actual code definitions in Section 2.4.

• Task Handler (0): The task handler actor 0 knows other metalevel actors (es, ¢ and A) and arranges

1 The term handle is used by B. Smith[7] for an extension of the concept of quotation. We use "handle" as the same way.

Watanabe & Yonezawa, REX/FOOL '90 (LNCS#489)

Matsuoka, Watanabe & Yonezawa, ECOOP '91Masuhara, Matsuoka, Watanabe & Yonezawa, OOPSLA '92

Hard to customize /reason about

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

a1(2, a1)

(1, (2, a1))

(2, (2, a1)) (3, a1)

a2

(1, a1)a3

(1, a3)

actor

groupboundary

ai baseaddress

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 [Watanabe 2013]

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

Application: Optimistic CCOP[Watanabe & Takeno 2013]

• Assumptions- single observer- contexts are linearly ordered- each message piggybacks the context of its sender• Algorithm

- Similar to Timewarp [Jefferson '85]

• Better concurrency- cf. pessimistic approach• Implicit

- Application programmer doesn't need to take care of context synchronization

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

Preliminary Evaluations: Ping-Pong

• Prototypes in Erlang- Plain: basic actor primitives (send/new/become)- GWR: basic (manually composed) group-wide metalevel- CCOP: an optimistic CCOP on GWR

• 1M round-trip messages between two actors

19

Plain GWR CCOP

Time (sec) 0.66 3.21 16.03

Preliminary Evaluations: Token Ring

• 200k round-trip messages in a ring of 100 actors

20

1 5 10 15 20 250

6

12

18

24

Number of Concurrent Messages

Exec

utio

n Ti

me

(sec

)

Plain

GWR

CCOP

Preliminary Evaluations: Sensor Network

• Simulation of a simple sensor network• Sensor Node

- has many sensors- computes results using measured values• Benchmark

- A master node sends requests to (and receives results from) the sensor nodes along a spanning tree of the network

- average turn around time

21

Plain GWR CCOP

Time (sec) 14.02 14.41 14.30

Evaluating the Rollback Mechanism

• A context change in the sensor example

• Rollback frequency (200 trials)

22

# of Rollbacks 0 1 2 3 4 5

Freq 80 24 16 41 32 7

Time (sec)Arithmetic 14.30Harmonic 14.54A then H 29.00

Summary

• Concurrent COP in Actor-Based Systems• Optimistic implementation of CCOP using GWR

- A reflective solution to implementing strictly synchronized context-changing in actor-based systems.

• Preliminary Evaluations using Prototypes in Erlang

• Future Work- Optimizations• context sensitive scheduling policies• application specific undoing/redoing for optimistic CCOP

- Loose adaptation to contexts- Language (abstraction) mechanisms for CCOP- Verification

23