RUTA PROVINCIAL Nº 24

is satisfied when the future u represented by v_u is resolved. The value stored in the future u is assigned to v. When the actor needs to synchronize with the result of a method call, a blocking statement (v_u.get) can be used instead. No release point is introduced, and the actor continues its execution only when the future u is resolved.

For simplicity, a non-empty class constructor only contains method call and ac- tor creation statements. This means that the class constructor performs no con- ditional checks, cannot explicitly block or introduce a release point, does no vari- able assignments apart from assigning variables to the generated futures and actor names. In other words, the constructor performs some initialization that cannot be performed through side-effect free expression evaluations.

An expression can be of the constantnull, the self name reference of the ac- torthis, a local variable or a method parameter x, a field f , a data constant c

(including data type constructors Co(e), strings and integers), or a function fn(e). A function can be, among others, an arithmetic function on integers, string con- catenation or a user-defined function as facilitated by the functional layer. An expression in our language is pure, meaning that its evaluation does not affect the current state of an actor. A reflective mechanism is not present, so the caller of a method call cannot be inferred from (the future attached to) the call.

3.3

Operational Semantics

The run-time semantics ofα

ABS

is given as a small-step, operational semantics under the assumption that we deal only with type-correct implementations. This issue is orthogonal to the focus of this thesis on verifying the dynamic behavior of the systems. A thorough treatment of the type system can be found in the

ABS

language description[Häh+10;JHSSS11].

The operational semantics is defined by reduction rules on configurations. The configurations contain the code being executed and the heap with the instantiated actors. A configuration is then represented by the parallel composition of these entities. This binary composition is associative and commutative, which allows us to focus on the interesting parts of the configurations in the reduction rules. A configuration is represented at run time as follows:

K ::= a[C, σ, l] actor a

| u[a, σ, l, s] task with future u

| u[a, σ, l, v] completed task with future u

An actor a[C, σ, l] has the name a, contains information about its class C, its instance state σ, and a lock to indicate whether the actor has an active task it is executing. σ is represented by a map from fields to values. The lock l either has the value of> and ⊥ (i.e., of boolean type), indicating whether an actor is currently executing a task or not, respectively. The entity u[a, σ, l, s] represents the task with future u of actor a representing the statement s the task needs to execute with a map from the local variables to values. The lock l indicates whether the task is active. The task is essentially the representation of an actor executing an asynchronous method call as we see in the reduction rules. The task name also corresponds to the future identity of that task. When the task is completed, the entity u[a, σ, l, s] is substituted by another entity u[a, σ, l, v] where v represents the resolved value for future u. The task is provided as a standalone entity instead of being part of the actor entity to simplify the reduction rules.

To specify the reduction rules, we add two constructs to the statement syntax ofα

ABS

given in Figure3.2:

s::= . . . |grab|release

The statementsgrab andreleasehandle the lock, allowing inactive tasks to ac-

quire the lock of the actor. In particular, the execution of thereleasestatement can be seen as the actual introduction of a release point in the actor. As we only have pure expressions, the order of how expressions are evaluated is not relevant. For simplicity, we use E(e)σ to evaluate an expression e with respect to some state

σ.

The reduction rules ofα

ABS

follow a standard sequential programming seman- tics, except for the parts dealing with the concurrency constructs. In Figure3.3, we provide a sample of reduction rules that deal with the cooperative multitasking approach. The reduction rules are of the form K   K0, reducing the configuration

K to K0. They are performed under a fixed underlying program. See AppendixB

for the complete operational semantics.

The two rulesR-GRABandR-RELEASEdealing with thegrabandreleasestate-

ments, respectively, change the configurations according to their desired descrip- tions. The locks of the task and the actor are synchronized to ensure that at most one task is active. These two statements are introduced when a method is invoked. As described by ruleR-CALL, a method call statement introduces the creation of a new task associated with the target actor. The statement this new task has to execute is the corresponding method body, padded with the grab and release

statements. With the padding, the new task has to first obtain the lock and later release the lock after the execution of the method is finished. The generated fu- ture identity is stored in the assigned variable. We assume that an asynchronous

3.3. Operational Semantics

R-GRAB

a[C, σ, ⊥] k u[a, σ, ⊥,grab; s]   a[C, σ, >] k u[a, σ, >, s] R-RELEASE

a[C, σ, >] k u[a, σ, >,release; s]   a[C, σ, ⊥] k u[a, σ, ⊥, s] R-CALL

u0fresh s00= body(m(x), C0) a0= E(e0)(σ0∪ σ)

val= E(e)(σ0_{∪ σ)} σ_u0= σinit[x 7→ val] s0=grab; repAwait(s00);release

a0[C0,σ00, l0] k a[C, σ0, l] k u[a, σ, l, x := e0.m(e); s]  

a0[C0,σ00, l0] k u0[a0,σu0,⊥, s0] k a[C, σ0, l] k u[a, σ[x 7→ u0], l, s]

R-AWAIT

u0= E(v)(σ0_{∪ σ)}

u0[a0,σ00, l0, s0] k a[C, σ0,>] k u[a, σ, >,awaitv?v0; s]  

u0[a0,σ00, l0, s0] k a[C, σ0,⊥] k u[a, σ, ⊥,release;grab;awaitv?v0; s] R-GET

u0= E(e)(σ0_{∪ σ)}

a[C, σ0, l] k u[a, σ, l, x := e.get; s] k u0[a0,σ0, l0, val]  

a[C, σ0, l] k u[a, σ[x 7→ val], l, s] k u0[a0,σ0, l0, val] R-RETURN

a[C, σ0,>] k u[a, σ, >,returne;release]   a[C, σ0,⊥] k u[a, σ, ⊥, E(e)(σ0∪ σ)]

Figure 3.3.: Reduction rules ofα

ABS

(selected statements)

call is always successful (i.e., the receiving actor is always able to create a task). Theawaitandgetstatements respectively provide the non-blocking and block- ing alternatives to retrieving the return result of a method call. The ruleR-AWAIT

highlights that when the return result is not ready, a new release point is intro- duced. Other variants of the rule exist to handle the other cases. The ruleR-GET

ascertains that the reduction on the statement can only go ahead if the return result is ready. This rule is the only rule dealing with the getstatement, so if a future is not yet resolved, the task cannot proceed with its execution and thus blocks.

A task terminates when thereturnstatement is executed. Because this state-

ment is placed at the end of a method body, we can process it together with the paddedreleasestatement (R-RETURN). The result of evaluating the expression e becomes the value held by the future u.

In document Obras y Acciones de Gobierno 2015 (página 119-122)