Veriﬁcation of Atomicity Preservation in Model-to-Code

Transformations using Generic Java Code

Dan Zhang

, Dragan Bosnacki

, Mark van den Brand

, Cornelis Huizing

, Ruurd Kuiper

Bart Jacobs

and Anton Wijs

Department of Mathematics and Computer Science, Eindhoven University of Technology,

Den Dolech 2, Eindhoven, The Netherlands

Department of Computer Science, Katholieke Universiteit Leuven, Leuven, Belgium

Keywords:

Model Transformation, Code Generation, Concurrency, Atomicity, Formal Veriﬁcation, Separation logic.

Abstract:

A challenging aspect of model-to-code transformations is to ensure that the semantic behavior of the input

model is preserved in the output code. When constructing concurrent systems, this is mainly difﬁcult due

to the non-deterministic potential interaction between threads. In this paper, we consider this issue for a

framework that implements a transformation chain from models expressed in the state machine based domain

speciﬁc language SLCO to Java. In particular, we provide a ﬁne-grained generic solution to preserve atomicity

of SLCO statements in the Java implementation. We give its generic speciﬁcation based on separation logic

and verify it using the veriﬁcation tool VeriFast. The solution can be regarded as a reusable module to safely

implement atomic operations in concurrent systems.

1 INTRODUCTION

Model transformation is a powerful concept in model-

driven software engineering (Kleppe et al., 2005).

Starting with an initial model written in a domain

speciﬁc language (DSL), other artifacts such as ad-

ditional models, source code and test scripts can be

produced via a chain of transformations. The initial

model is typically written at a conveniently high level

of abstraction, allowing the user to reason about com-

plex system behaviour in an intuitive way. The model

transformations are supposed to preserve the correct-

ness of the initial model, thereby realising a frame-

work where the generated artifacts are correct by con-

struction. A question that naturally arises for model-

to-code transformations is how to guarantee that func-

tional properties of the input models are preserved in

the generated code (Rahim and Whittle, 2013). In par-

ticular, this requires semantic conformance between

the model and the generated code. For models in the

area of safety-critical concurrent systems, the main

complication to guarantee this equivalence involves

the potential of threads to non-deterministically inter-

act with each other.

Speciﬁcally, when variables are shared among

multiple threads, the absence of race conditions is cru-

cial to guarantee that no undesired updates of those

variables can be performed. This relates to the no-

tion of atomicity of the instructions executed by the

threads. For instance, if two threads both increment

the value of a variable x by one, then only when each

of those increments can be performed atomically is

it ensured that the ﬁnal value of x equals the initial

value plus two. Achieving atomicity of program in-

structions can be done using various techniques, such

as locks, semaphores, mutexes, or CPU instructions

such as compare-and-swap.

Also in modeling languages, atomicity is an im-

portant concept, to simplify the reasoning about pro-

gram instructions by abstracting away the atomicity

implementation details. Hence, an important require-

ment for model-to-code transformations is that the

atomicity of the statements in the modeling language

is preserved in the code. A conceptual solution would

be to map each statement to an atomic block in the

implementation language. Strictly speaking, a block

of instructions is atomic if during its execution no

instruction of another thread is allowed to be exe-

cuted. However, such a deﬁnition is too strong for

practical purposes, since it excludes the possibility

for threads to run truly concurrently in cases when

they access different variables, and therefore do not

interfere with each other. For this reason, it is usually

replaced with weaker notions that still ensure non-

interference. One such version, sometimes called se-

578

Zhang, D., Bosnacki, D., Brand, M., Huizing, C., Kuiper, R., Jacobs, B. and Wijs, A.

Veriﬁcation of Atomicity Preservation in Model-to-Code Transformations using Generic Java Code.

DOI: 10.5220/0005689405780588

In Proceedings of the 4th International Conference on Model-Driven Engineering and Software Development (MODELSWARD 2016), pages 578-588

ISBN: 978-989-758-168-7

rializability (Biswas et al., 2014), allows instruction

blocks to be executed concurrently as long as their in-

dividual results are not affected by the other blocks.

In this paper, we demonstrate how one can estab-

lish that a model-to-code transformation transforms

atomic statements in modeling languages to blocks of

program instructions that are serializable. To illus-

trate this, we focus on a DSL called Simple Language

of Communicating Objects (SLCO) (Engelen, 2012),

on the one hand, and the Java programming language

on the other hand. It should be stressed, though,

that our approach is suitable for any combination of a

modern imperative programming language with con-

currency and a modeling language that is, like SLCO,

based on state machines that can be placed in paral-

lel composition, and can change state by ﬁring transi-

tions with atomic statements (for instance, UML state

machines).

SLCO was originally introduced to model com-

plex embedded concurrent systems by means of state

machines in combination with variables. A technique

to verify SLCO-to-SLCO transformations has been

proposed in (Wijs, 2013; Wijs and Engelen, 2013;

Wijs and Engelen, 2014). In this paper we focus on

the correctness of a fully automated model-to-code

transformation in which each SLCO state machine

is transformed to an individual Java thread. In or-

der to deﬁne the transformation in a modular way,

and thereby improving its maintainability, we divide it

into two parts, one part transforming SLCO concepts

into generic code, and the other part transforming the

aspects that are speciﬁc for the particular input SLCO

model into speciﬁc code. The speciﬁc code may re-

fer to the generic code to use the model-independent

concepts. An example of a generic SLCO concept is

the communication channel, while a particular state

machine is an example of a concept speciﬁc for a

given SLCO model. This way of working provides a

clear maintenance advantage, as the implementations

of generic concepts can be updated without affecting

the overall transformation machinery. Another bene-

ﬁt is that the generic code needs to be veriﬁed only

once. Each class of the generic code can be speciﬁed

and veriﬁed in isolation, allowing for modular veriﬁ-

cation.

In the past, we have outlined the approach de-

scribed above in (Zhang et al., 2014), in which we

have also identiﬁed the main challenges. As a ﬁrst

step towards having completely veriﬁed generic code,

we focussed on the SLCO communication channel,

and formally veriﬁed, using the VeriFast tool (Jacobs

et al., 2011), that its semantics is captured by the Java

construct to which we transform it (Bo

sna

cki et al.,

2015).

Contributions. Our contribution in this paper is

three-fold. First of all, we discuss how we have im-

plemented, speciﬁed, and veriﬁed a protection mech-

anism to access shared variables in such a way that

the code blocks implementing atomic DSL statements

are guaranteed to be serializable. This generic mecha-

nism is used in our framework to automatically trans-

form SLCO models into multi-threaded Java code,

but the solution is general enough to be used in other

model-to-code transformations as well.

The mechanism employs a ﬁne-grained ordered-

locking approach. A coarse-grained approach tends to

negatively impact the performance of multi-threaded

software, while a lock-free approach, in particular us-

ing atomic instructions such as compare-and-swap, is

necessarily restricted to work only for statements that

involve a single shared variable.

Second, we show the feasibility to verify the atom-

icity of generic statements by focussing on the SLCO

assignment statement. We formally prove its imple-

mentation against a speciﬁcation of non-interference

using the VeriFast tool (Jacobs et al., 2011). Being

based on separation logic (Reynolds, 2002), VeriFast

is suitable to deal with aliasing and concurrency in

Java, as well as with race conditions using the con-

cept of ownership of shared resources between multi-

threaded programs.

Finally, we introduce a wrapper class pattern to

perform modular veriﬁcation. With the wrapper class,

it is possible to encapsulate data structures that are

used in the code, but are not subjected to veriﬁcation

(for instance, because they have already been veriﬁed

at an earlier stage possibly using a different tool).

The remainder of the paper is structured as fol-

lows. In Section 2 we brieﬂy explain SLCO, the

model transformation from SLCO to Java, and the es-

sentials of separation logic and VeriFast. Section 3

describes the implementation of atomicity of SLCO

statements in Java, as well as the implementation of

the generic wrapper class. In Section 4, we demon-

strate how to specify and verify the Java implemen-

tation. Section 5 discusses related work, and Section

6 contains our conclusions and a discussion about fu-

ture work.

2 PRELIMINARIES

2.1 SLCO

In SLCO, systems consisting of concurrent, commu-

nication components can be described using an in-

tuitive graphical syntax. Objects, as instances of

classes, can communicate via channels, over which

Veriﬁcation of Atomicity Preservation in Model-to-Code Transformations using Generic Java Code

579

they send and receive signals. Objects are connected

to channels via their ports. Each object consists of a

number of ﬁnite state machines and shared variables.

The state machines in an object can use private, lo-

cal variables, and communicate with each other via

the shared variables in the object. Each transition

of a state machine may have an associated SLCO

statement.

SLCO offers ﬁve types of atomic state-

ments: SendSignal, ReceiveSignal, (Boolean) Ex-

pression, Assignment, and Delay.

State machines, like the ones in Figure 1, are

used to specify object behavior. Each transition has

a source and target state, and the statement associ-

ated with a transition is executed when the transition

is ﬁred. Parallel execution of transitions is formalized

in the form of interleaving semantics. A transition is

enabled if the statement is enabled or there is no state-

ment associated with the transition. For communica-

tion between objects, there are statements for sending

and receiving signals. The statement send T(s) to In-

Out, for instance, sends a signal named T with a single

argument s via port InOut. Its counterpart receive T(s)

from InOut receives a signal named T from port In-

Out and stores the value of the argument in variable s.

Statements such as receive Q(m | m >= 0) from In2

offer a form of conditional signal reception. In this

example, only those signals are accepted whose ar-

gument is at least equal to 0. Boolean expressions,

such as m=6, denote statements that block until the

expression holds. Assignment statements, such as

m := m + 1, are always enabled, and are used to as-

sign values to variables. Finally, time is incorporated

in SLCO by means of delay statements. For exam-

ple, the statement after 5 ms blocks until 5 ms have

passed since the moment the source state was entered.

As already mentioned, variables can be shared by

multiple state machines. In Figure 1, the three state

machines in the left rectangle are part of the same ob-

ject, and m is shared by them: assigning a value to m

in the second state machine may affect the truth-value

of the expression in the third. Statements of types Ex-

pression, Assignment, ReceiveSignal and SendSignal

can all refer to variables shared by multiple state ma-

chines.

2.2 Model Transformation

Recently, we developed an automated model-to-code

transformation (AuthorsOfThisPaper, 2015) from

SLCO models to multi-threaded Java programs. The

There is an extended version of SLCO allowing multi-

ple statements per transition. In this paper, we consider the

basic language, since extended SLCO models can be trans-

lated to basic SLCO models (Engelen, 2012).

m == 6

send S(”a”) to InOut

receive T(s | true)

from InOut

Rec2a

receive Q(m | m >= 0) from In2

m := m + 1

Rec1

receive P(v | v == false)

from In1

Com0

Com1

send P(true)

to Out1

Com2

after 5 ms

send Q(5) to Out2

receive S(s | true)

from InOut

send T(s) to InOut

Rec2b

SendRec0

SendRec1

SendRec2

Com3

Com4

Figure 1: State machines in an SLCO model.

transformation consists of multiple steps. Here we fo-

cus on the last step that transforms SLCO models to

Java code. The preceding steps are transformations

from SLCO models to more reﬁned SLCO models us-

ing Xtend.

These steps are used to deal with poten-

tial semantic and platform differences.

After this problem has been resolved, the last step

from SLCO to Java is applied, which is implemented

in the Epsilon Generation Language (EGL) (Kolovos

et al., 2011) based on Eclipse. The output is deﬁned

by means of templates that are used by the genera-

tor to produce the Java code. The generator applies

transformation rules, deﬁned in the template, to all

the meta model objects which results in generation of

the corresponding Java code. This Java code is con-

structed by combining speciﬁc code implementing the

behavior of the input model with generic code imple-

menting model-independent SLCO concepts. Exam-

ples of such concepts are the communication channel,

the various types of statements, and a list datatype

to store the shared variables owned by an object.

The transformation achieves a one-to-one mapping

between the state machines in an SLCO model and

the threads in the derived program. Finally, the spe-

ciﬁc code is combined with the generic code to obtain

complete, executable code that should behave as the

SLCO model speciﬁes. In order to guarantee that im-

portant properties of the input model are preserved,

the transformation needs to be veriﬁed. In this paper,

we focus on verifying that the atomic nature of SLCO

statements is preserved when they are transformed to

blocks of Java instructions. The main complication

when verifying this lies in the fact that the statements

may access shared variables, and hence can poten-

www.eclipse.org/xtend

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

580

tially interfere with each other when executed con-

currently. We use separation logic to specify the code

blocks.

2.3 Separation Logic

Separation logic (Reynolds, 2002; O’Hearn et al.,

2001) is an extension of Hoare logic (Owicki and

Gries, 1976) that supports reasoning about shared

memory which can be referenced from more than one

location. Therefore, separation logic is used to de-

scribe the heap – a mapping from object IDs and ob-

ject ﬁelds to values, where a value is an object or a

constant. The basic heap expressions are emp, the

empty heap, satisﬁed by states having a heap with no

entries, and E 7→ F (read as “E points to F”), a sin-

gleton heap, satisﬁed by a state with a heap consist-

ing of only one entry on address E with content F.

For instance, o. f 7→ v means that ﬁeld f of object o

has value v. To represent complex heaps (e.g., dy-

namic data structures) the logical operator ‘∗’, called

separation conjunction is used. Expression P*Q as-

serts that the heap contains disjoint parts such that P

holds in one part and Q holds in the other. So, un-

like its counterpart o. f 7→ v ∧ o. f 7→ v, the expression

o. f 7→ v ∗ o. f 7→ v evaluates to false because the two

heap components are not disjoint. In a concurrent set-

ting, this is used to detect data races, i.e., a simul-

taneous access to the same memory objects by two

different threads.

In addition to the standard rules of the Hoare

framework, separation logic has the frame rule. It al-

lows to extend the speciﬁcation of a program segment

C with assertion R. The axiom requires that no free

variable in R is modiﬁed by C:

{P} C {Q}

{P ∗ R} C {Q ∗ R}

(frame)

Separation logic uses the principle of a minimal

memory footprint, meaning that a separation asser-

tion describes a unique heap. For example, the as-

sertion o. f 7→ a ∗ o.g 7→ b describes a heap consisting

of exactly two entries. This property together with

the requirement that the heaps of two separate threads

are disjoint, makes it possible to give a natural own-

ership interpretation of a shared resource. If a separa-

tion logic assertion P holds at some program location

on a thread, then we say that the thread owns the part

of the heap described by P at that location.

The portions of the heap associated with each

thread are always mutually disjoint. When a thread

acquires a shared object, it claims the ownership of

the state associated with the variable; when releasing

the variable, it must return the ownership of the corre-

sponding piece of state. At all stages, our use of sep-

aration logic ensures that each piece of the heap is ac-

cessed by at most one thread. It thus becomes possible

to reason about concurrent programs in which owner-

ship of a shared variable can be perceived to transfer

dynamically between threads. We achieve this dy-

namic transfer by associating invariants to locks of

shared objects. The invariant representing the envi-

ronment of the thread expresses the ownership of the

shared variable.

By acquiring a lock, the veriﬁed program compo-

nent also acquires the lock invariant representing the

heap that corresponds to the shared variables. The in-

variant carries a full permission to change the actual

shared variables. By releasing the lock, the compo-

nent releases, together with the invariant, also the ac-

quired ownerships. This is expressed by the following

rules for the lock and unlock operations

{emp} v.lock() {I

(l)} (L)

(l)} v.unlock() {emp} (UL)

where I

(l) is the invariant associated with lock l of

variable v.

To specify read-only sharing of variables frac-

tional ownerships (permissions) are used. A frac-

tional permission with fraction φ is denoted by

[φ]o. f 7→ v, where 0 < φ ≤ 1. When φ = 1, the frac-

tion is omitted and we obtain the usual o. f 7→ v. This

case expresses full ownership, allowing both read and

write access.

2.4 VeriFast

The VeriFast tool is a program veriﬁer for se-

quential and concurrent C and Java programs.

Programs are annotated with assertions writ-

ten as separation logic formulae. The veri-

ﬁer can check for NULLPointerException or

ArrayIndexOutOfBoundsException. For con-

current programs, it checks that the program does

not contain data races (memory safety). When

the veriﬁcation succeeds and it reports no error,

the assertions and method contracts (preconditions

and postconditions) are respected in every program

execution. In the veriﬁcation, VeriFast executes

method bodies symbolically. The symbolic execution

of a triple {P} C {Q} starts in the symbolic state

corresponding to the precondition P. If the triple is

correct, each ﬁnite execution should eventually reach

a symbolic state implying Q.

Veriﬁcation of Atomicity Preservation in Model-to-Code Transformations using Generic Java Code

581

3 IMPLEMENTING SLCO

ATOMICITY

In this section, we give the formal deﬁnition of atom-

icity of SLCO statements as well as a semantically

comparable form of non-interference called serializ-

ability (Biswas et al., 2014) for the Java blocks im-

plementing those statements. Furthermore, to fa-

cilitate the transformation of SLCO statements to

Java code, speciﬁcally to handle accessing shared

variables, we introduce the generic data structure

SharedVariableList.

In our model-to-code transformation, each SLCO

statement s in a state machine M is transformed into

a block of Java instructions σ = s

;. . . ;s

to be

executed by a thread t

. Strictly speaking, preserv-

ing atomicity of s in σ means that no instruction s

some thread t 6= t

is allowed to be executed between

the beginning and end of the execution of σ.

However, implementing atomicity in this strict

sense is practically undesirable when constructing

multi-threaded software, since it disallows true par-

allelism. That is why we replace this strong atom-

icity requirement with serializability. Serializabil-

ity guarantees that for any concurrent execution of

(atomic) Java blocks there exists a sequential execu-

tion of those blocks that is indistinguishable from the

concurrent execution, in terms of the ﬁnal effect on

the global system state. More explicitly, let σ and σ

be two different instruction blocks to be executed by

different threads t

, t

. Let q

be a global state in the

Java model in which both σ and σ

can start a concur-

rent execution and let q

be a state in which the system

ends up after the execution of both σ and σ

. Then,

also is obtained after sequential execution of the

sequence σσ

or σ

σ (or both). Hence, we may rea-

son about their execution as if σ was ﬁrst completely

executed before σ

was started, or vice versa. (Note

that this also covers the case when σ may prevent the

execution of σ

or vice versa.) The extension of the

concept of serializability to an arbitrary number of in-

struction blocks σ

is straightforward.

The state of a system is determined by the val-

ues of its variables. In SLCO, statements may access

variables shared by multiple state machines (see Sec-

tion 2). Therefore, in the corresponding Java code,

multiple threads may access the same shared vari-

ables. In order to realize serializability in such a set-

ting, it must be ensured that an instruction s

of some

thread t cannot affect the variables accessed by the in-

structions in a block σ of thread t

6= t running con-

currently.

The way in which shared variables are protected

has a signiﬁcant impact on the overall performance

of concurrent programs. For example, using one sin-

gle global lock to protect a list frequently accessed

by several threads is likely to scale much worse than

when each element in that list is individually lockable.

SLCO statements may require access to just a sub-

set of the shared variables of an object. Therefore,

each element in the list of shared variables is assigned

its own lock for read and write access. This gives a

better performance than using a single lock for the

complete list. In this way we achieve serializability,

as shown in Section 4.2.

Individual locking may introduce deadlocks. We

use the technique of ordered locking [Havender,

1968] to prevent them. The ordered locking mech-

anism guarantees that when multiple threads compete

over a set of variables, one thread is always able to

acquire access to all of them. Of course, other threads

requiring access to different shared variables are able

to access these concurrently.

Note that the locks can be released in an arbitrary

order. Obviously there is no deadlock during the re-

leasing since at least one method - namely, unlock is

active. After the locks are released we again have the

situation in which multiple threads compete for the

locks in ﬁxed order.

Our synchronization mechanism for

shared variables is shown in Listing 1. The

SharedVariableList, as a wrapper class, is in-

troduced to abstract away how the list of shared

variables is implemented. It can be used to encap-

sulate Java data structures. The methods lock and

unlock are used to acquire and release each lock of

the shared variables in the list.

Listing 1: Class Statement

1 p ub lic ab st rac t c lass S t ate me nt {

2 p rot ec te d Sh a re d V a ri a bl e L i s t v a r i ab l e s Li s t ;

3 .. .

4 p ub li c v oid loc k ( )

5 {

6 fo r ( int i = 0; i < va r i a bl e s L is t . si z e ( ) ; i + + )

7 {

8 v a ri a b l es L i s t . g et ( i ). lo c k . l oc k () ;

9 }

10 }

11 p ub li c v oid un lo ck ()

12 {

13 fo r ( int i = 0; i < va r i a bl e s L is t . si z e ( ) ; i + + )

14 {

15 v a ri a b l es L i s t . g et ( i ). lo c k . u n l oc k () ;

16 }

17 }

18 }

The class Assignment as a subclass of class

Statement (Listing 2) contains a method called

lockAndAssign that can be used to safely assign a

new value to a shared variable. The abstract method

assign is implemented in the subclass which is re-

lated to a concrete SLCO assignment. When a thread

attempts to execute the method assign, it will be de-

layed until all locks in the variablesList of vari-

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

582

ables to be accessed by the assign method are not

being used anymore by other threads.

Listing 2: Class Assignment.

1 p ub li c a b s t r a ct cl a ss A ss ig nm e n t ex te nd s St a t em en t

{

2 .. .

3 p ub li c a b s t r a ct voi d a ss ig n ( ) ;

4 p ub li c v oid l o c kA n d A ss i g n () {

5 l o ck () ;

6 a ss ig n ( ) ;

7 u nl oc k ( ) ;

8 }

9 }

As already mentioned, to store shared variables,

we introduce a wrapper class SharedVariableList.

Listing 3 shows its declaration. The concept of wrap-

per classes is quite common in object-oriented pro-

gramming and it is a pattern in object-oriented de-

velopment. The wrapper class is used to hide in-

formation of concrete Java data structures, which al-

lows modular veriﬁcation. Parts of the code that

use SharedVariableList can be veriﬁed without in-

volving the data structure; in fact, it may not even

have been implemented yet. This helps to scale ver-

iﬁcation to larger programs, since the wrapper class

needs to be analyzed only once, instead of once per

call. Finally, modifying the implementation of the

data structure encapsulated by the wrapper class never

breaks correctness of its callers. This allows for si-

multaneous development and veriﬁcation of code.

Listing 3: Declaration of class SharedVariableList.

1 f in a l cla ss S h a re d Va r i a bl e Li s t {

2 p ub li c Sh ar e d V a r i ab l eL i s t () ;

3 p ub li c i n t s i ze () ;

4 p ub li c S h ar e dV ar i ab l e ge t ( in t in de x ) ;

5 b oo le an add ( S ha r e d Va r ia bl e e ) ;

6 }

4 SPECIFYING AND VERIFYING

SLCO ATOMICITY

In the previous section, we explained how the atom-

icity of SLCO statements can be implemented using

serializability. We can use separation logic in Veri-

Fast to verify the serializability, i.e., the fact that there

is non-interference between different threads.

The interpretation of correctness depends cru-

cially on rules L and UL for the lock and unlock

operations from Section 2.3. In our case in rules L

and UL invariant I

(l) is of the form v 7→ , i.e., ex-

presses ownership of the variable v. By rule L, I

(l)

is guaranteed to hold after lock, i.e., in the begin-

ning of the protected code block. This means that

the corresponding thread acquires the ownership of

v. Similarly, at the end of the block, after unlock,

the ownership of v is released together with invariant

(l). Let V be the list of shared variables associated

with the statement implemented in the block. By ex-

ecuting lock for each variable in V , using a combi-

nation of the L and UL rules and the frame rule from

Section 2.3, an assertion I

is established which is the

conjunction of the invariants I

(l), for all v ∈ V . I

can

be seen as an invariant of the list V which expresses

ownership of all variables in V by the thread. The con-

crete setting of our model transformation ensures that

no shared variable in V is acquired or released within

the protected code block. This is achieved by sim-

ply not using lock and unlock within the protected

block, since these are the only statements with which

one can acquire or release ownership. Together with

the fact that invariant I

holds at the beginning and

at the end of the block, this implies non-interference

since all variables are held exclusively by the thread

during the execution of the block.

VeriFast supports modular veriﬁcation in the sense

that each method is veriﬁed separately. In this, each

method relies on its environment to comply with the

invariant. This is checked during the veriﬁcation

when several threads are combined. In the follow-

ing sections, we specify and verify the atomicity of

Java constructs corresponding with SLCO statements

using separation logic via VeriFast.

In VeriFast, for each veriﬁed Java source ﬁle

(.java) there is a corresponding speciﬁcation ﬁle

(.javaspec). The .java ﬁle contains implementations,

speciﬁcations, annotations, and predicates, while the

.javaspec ﬁle contains only declarations of predicates

and speciﬁcations of methods with a semicolon in-

stead of a method body. A .javaspec ﬁle can be used

to verify client programs even without having the cor-

responding .java ﬁle that contains the deﬁnitions and

the implementations mentioned in the .javaspec ﬁle.

Thus, the client programs are users of the .javaspec

ﬁles. For example, we only need to provide a pure

(i.e., containing no implementations) speciﬁcation ﬁle

SharedVariableList.javaspec to VeriFast in order to

verify the Statement class.

4.1 Class SharedVariableList

Speciﬁcation

Class SharedVariableList is speciﬁed in sepa-

ration logic in a way that is in fact independent of

the Java programming language. In Listing 4, the

class SharedVariableList provides methods for

modifying and querying its instances, such as size,

add and get.

Veriﬁcation of Atomicity Preservation in Model-to-Code Transformations using Generic Java Code

583

Listing 4: Speciﬁcation of class SharedVariableList.

1 f in a l cla ss S h a re d Va r i a bl e Li s t {

2 /* @ p re d i c a t e L is t ( list < S h ar ed Va ri ab le > el e m e n t s ) ;

@ */

3 p ub li c Sh ar e d V a r i ab l eL i s t () ;

4 // @ r eq ui re s tru e ;

5 // @ e ns ur es Lis t ( n i l ) ;

6 p ub li c i n t s i ze () ;

7 // @ r eq ui re s [ ? f ] Lis t ( ? es ) ;

8 // @ e ns ur es [ f ] L i st ( e s ) & *& res ul t == len gt h ( es ) ;

9 p ub li c S h ar e dV ar i ab l e ge t ( in t in de x ) ;

10 // @ r eq ui re s [ ? f ] Lis t ( ? es ) &* & 0 <= i nd ex &*& ind ex

< l en gt h ( es ) ;

11 // @ e ns ur es [ f ] L i st ( e s ) & *& res ul t == n th ( i n dex , es

);

12 b oo le an add ( S ha r e d Va r ia bl e e ) ;

13 // @ r eq ui re s Lis t (? es ) ;

14 // @ e ns ur es Lis t ( a p p en d ( es , c on s (e , n i l ) ) ) & *&

re su l t ;

15 }

The VeriFast speciﬁc text, e.g., speciﬁcations and

declarations of auxiliary variables introduced only for

veriﬁcation purposes, is located inside special com-

ments delimited by @.

We express the state of the sharedVariableList

instances using a mathematical list predeﬁned in Ver-

iFast as follows: The empty list is denoted by nil and

a nonempty list starting by an element h and a tail t is

denoted by cons(h,t). In particular, predicate List

is an abstract predicate that provides an abstract repre-

sentation of the contents of the list of shared variables.

More concretely, parameter elements is a mathemat-

ical list containing the actual program variables that

are stored in the list. The actual implementation can

be, for instance, a dynamic list or an array. Using the

abstract predicate we can hide such implementation

details during the veriﬁcation. Note that List remains

undeﬁned in this speciﬁcation stage. Its deﬁnition can

be provided later together with the implementation of

SharedVariableList.

The pre- and postconditions form the contracts

of the methods and are denoted by the keywords

requires and ensures, respectively, like in lines 4-

5 in Listing 4. This contract of the constructor guar-

antees that an object is created corresponding to an

empty list, regardless of the precondition.

The speciﬁcation of size in lines 7 and 8 states

that the method returns the length of the list. Com-

ponent assertions of pre- and postconditions are sepa-

rated by the spatial conjunction denoted by &*&. Both

[?f] and [f] are fractional ownerships. The ques-

tion mark ? in front of a variable means that the

matched value is bound to the variable and all later

occurrences of that variable in the contract refer to

this matched value. In our case the value of the frac-

tional permission f in the precondition in line 7 must

be the same as the one in the postcondition in line 8.

Hence, the precondition in line 7 [?f]List(?es) ex-

presses both that a fractional ownership with fraction

f is required for the shared variable list correspond-

ing with the mathematical list es, and records f and

es. The postcondition speciﬁes that the method re-

turns the ownership of es to the caller with the same

fraction f and the result that is returned by size is

the length of es. result is a reserved variable name

representing the return value of the method.

The precondition of get (line 10) requires that a

valid element index is provided as an input parame-

ter. The postcondition expresses that the element at

position index in list es is returned using the mathe-

matical function nth.

Unlike for other methods, the precondition of add

(line 13) requires full ownership of the list es. As a

result, the caller who owns es is allowed to insert an

element into the list. Finally the method add returns

the ownership of a new list that combines the list es

with the newly inserted element e using the function

append.

4.2 Class Statement Speciﬁcation

The speciﬁcation of class Statement is shown in

Listing 5. The predicate constructor lock inv in

line 2 is essential for the preservation of serializabil-

ity. It deﬁnes the lock invariant I

(l) associated with

the lock of a variable v passed as a parameter. The

assertion v.value |-> asserts the full ownership

of v.value. The underscore ’ ’ denotes an arbitrary

value.

The recursive predicates locks and invariants

in lines 3-7 and 8-12, respectively, are used to specify

data structures without static bound on their size. The

body of each predicate is a conditional assertion. If

vs is null (the base case of the induction) then the

value of predicate locks is true (line 5); otherwise,

the inductive step asserts that the lock of the ﬁrst ele-

ment of the list vs, head(vs) is partially owned. This

is given by return [ ]head(vs).lock |-> ?lock

in line 7, where [ ] denotes an unspeciﬁed fraction.

Besides that, invariant lock inv(head(vs)) is asso-

ciated with the lock of the ﬁrst element, via the pred-

icate ReentrantLock. Predicate ReentrantLock

is deﬁned by VeriFast as a speciﬁcation of the

ReentrantLock class. In a similar fashion, the re-

cursive predicate invariants states that a conjunc-

tion of invariants corresponding to the (locks of the)

variables in list vs is recursively built. As mentioned

above, for each variable the corresponding invariant

is given by the speciﬁcation lock inv(head(vs)).

Predicate Statement lock() is actually deﬁned

in Listing 6 and denotes that the Statement ob-

ject is in a valid state corresponding to an abstract

value given by the mathematical object list of shared

variable objects vs. The body of method lock

needs to establish the above mentioned invariant I

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

584

of each variable in list vs which is expressed by the

postcondition invariants(vs). The postcondition

invariants(vs) is also one part of the precondi-

tion in the method unlock. By calling the method

unlock, invariant I

of each variable in list vs is not

guaranteed to hold anymore. After that, other threads

can acquire the ownership of those variables through

the method lock.

Listing 5: Abstract Speciﬁcations of Class Statement.

1 /* @

2 p r ed i c a te _ c t or l oc k_ in v ( S h a re d Va ri a bl e v ) (; ) = v .

va l ue | - > _ ;

3 p r e d ic at e l oc ks ( list < S h a r e d V a r i a b l e > vs ;) =

4 vs == n il ?

5 t r ue

6 :

7 [_ ] h ea d ( vs ) . l o ck | - > ? l ock &*& [ _ ] lo ck . R e e nt r a n tL o c k (

lo ck _i nv ( h e ad ( vs ) )) & * & l oc k s ( tai l ( vs ) ) ;

8 p r e d ic at e in va ri a n t s ( lis t < S ha re dV ar ia bl e > v s ;) =

9 vs == n il ?

10 t r ue

11 :

12 l o c k _ i n v ( he ad ( v s ) ) () &*& in v a ri an ts ( t ail ( vs ) ) ;

13 @ */

14 c la s s St at em en t {

15 // @ p re d i c a t e St at e m e nt _ l o ck ( list < S ha re d V a r i a b l e > vs )

;

16 v o id loc k () ;

17 // @ r eq ui re s [ _ ] S ta t em e n t _l o c k (? v s ) ;

18 // @ e ns ur es i n v ar ia nt s ( v s ) ;

20 v o id un lo ck () ;

21 // @ r eq ui re s [ _ ] S ta t em e n t _l o c k (? v s ) & *& in va ri a n t s ( vs

);

22 // @ e ns ur es tru e ;

23 }

4.3 Class Statement Veriﬁcation

Above we gave the formal speciﬁcation of the class

Statement in an abstract, mathematically precise and

implementation-independent way. Providing speciﬁ-

cation of SharedVariableList is a critical factor to

verify the implementation of class Statement. Ad-

ditional predicates and annotations are also needed

to verify the implementation of class Statement, as

shown in Listing 6.

Listing 6: Veriﬁcation annotations for class Statement.

1 /* @

2 p r ed i c a te _ c t or l oc k_ in v ( S h a re d Va ri a bl e v ) (; ) = . ..

3 p r e d ic at e l oc ks ( list < S h a r e d V a r i a b l e > vs ;) = . ..

4 p r e d ic at e in va ri a n t s ( lis t < S ha re dV ar ia bl e > v s ;) = ...

5 @ */

6 c la s s St at em en t {

7 S h ar e dV a r i a b l eL i st v ar i ab le s L i st ;

8 // @ p re d i c a t e St at e m e nt _ l o ck ( list < S ha re d V a r i a b l e > vs )

= thi s . va r i a bl e s L is t | - > ? a & *& a . Li st ( v s ) & *&

lo c ks ( vs ) ;

9 v o id loc k ()

10 // @ r eq ui re s [ _ ] S ta t em e n t _l o c k (? v s ) ;

11 // @ e ns ur es i n v ar ia nt s ( v s ) ;

12 {

13 fo r ( int i = 0; i < va r i a bl e s L is t . si z e ( ) ; i + + )

14 // @ r eq ui re s [ _ ] v ar i ab le s Li st |- > ? b &*& [ _ ] b . L is t ( vs

) & *& [ _] lo ck s ( d rop (i , vs ) ) &* & i >= 0 &*& i <=

le ng t h ( v s ) ;

15 // @ e ns ur es i n v ar ia nt s ( dr op ( o ld_i , vs ) ) ;

16 {

17 // @ d r op _ n _ pl u s _ on e ( i , vs ) ;

18 v a ri a b l es L i s t . g et ( i ). lo c k . l oc k () ;

19 }

20 }

21 v o id un lo ck ()

22 // @ r eq ui re s [ _ ] S ta t em e n t _l o c k (? v s ) & *& in va ri a n t s ( vs

);

23 // @ e ns ur es tru e ;

24 {

25 fo r ( int i = 0 ; i < v a r ia b l e sL i s t . si ze () ; i + +)

26 // @ r eq ui re s [ _ ] v ar i ab le s Li st |- > ? b &*& [ _ ] b . L is t ( vs

) & *& [ _] lo ck s ( d rop (i , vs ) ) &* & i nv ar ia n t s ( dr op (

i , vs ) ) & *& i >= 0 & * & i <= l e n gt h ( vs ) ;

27 // @ e ns ur es tru e ;

28 {

29 // @ d r op _ n _ pl u s _ on e ( i , vs ) ;

30 v a ri a b l es L i s t . g et ( i ). lo c k . u n l oc k () ;

31 }

32 }

33 }

The part in lines 1-5 in Listing 6 is identical

to lines 1-13 in the speciﬁcation Listing 5. Line

8 in Listing 6 contains the deﬁnition of predi-

cate Statement lock which in Listing 5 was only

speciﬁed. The part this.variablesList |-> ?a

states that ﬁeld variableList is deﬁned. The last

two conjuncts a.List(vs) &*& locks(vs) relate

variableList with the mathematical variable vs of

type list and moreover the variables in vs are con-

nected to their corresponding locks. The contract of

method lock in lines 10-11 is the same as the one in

Listing 5.

In line 13 we use a for loop to obtain the lock

of each element in the SharedVariableList. Be-

sides loop invariants, VeriFast supports also loop ver-

iﬁcation by specifying a loop contract consisting of

a precondition and a postcondition (Tuerk, 2009).

Then the loop is veriﬁed as if it were written us-

ing a local recursive function. The contract spec-

iﬁes the permissions used only by a speciﬁc recur-

sive call (i.e., corresponding to a speciﬁc value of the

loop counter i). The precondition in line 14 matches

variablesList with variable b ([ ]variablesList

|-> ?b), relates b to vs ([ ]b.List(vs)), associates

the variables from the i-th to the vs.length-1-th

in list vs ([ ]locks(drop(i,vs))) to their locks,

and ﬁnally limits the range of the counter i (i >= 0

&*& i <= length(vs)). The segment vs from i to

vs.length-1 is obtained using the built-in function

on lists drop. In a similar way in the postcondition

in line 15, the list tail starting with old i is obtained

as an argument of the predicate invariants. Vari-

able old i refers to the value of the variable i at the

start of the virtual function call (loop body). After

the top virtual recursive call backtracks, i.e., after the

loop termination, old i equals 0. This implies the

validity of the conjunction of all lock invariants and

consequently the ownership of all variables in vs.

Lemma functions are used to help VeriFast to

transform one assertion to another. The contract

of a lemma function corresponds to a theorem, its

body to the proof, and a lemma call to an applica-

tion of the theorem. In our case lemma function

Veriﬁcation of Atomicity Preservation in Model-to-Code Transformations using Generic Java Code

585

drop n plus one(i,vs) in line 17 tells the veriﬁer

that drop(n,vs) is equivalent to the concatenation of

the element nth(vs) with the list drop(n+1,vs).

The detailed annotation of unlock (lines 21-32)

uses the same concepts as the annotation of lock,

therefore we do not discuss the former explicitly.

It expresses that in each iteration the loop invariant

shrinks instead of growing with the addition of a new

conjunct, i.e., invariant associated to a lock.

The speciﬁcation and annotation in the cur-

rent section is sufﬁcient to prove that predicate

invariants, which corresponds to I

, holds in the

beginning and the end of the block implementing the

statements. In Listing 2 this means that invariants

holds immediately after lock in line 5 and immedi-

ately before the unlock in line 7. The validity of

invariants ensures ownership of the variables in

sharedVariables. As discussed above, by construc-

tion of our transformation (i.e., by not using lock and

unlock within the protected block of the statement

translation) we ensure that the block does not release

this ownership. For example, in Listing 2 methods

assign in line 6, as well as the implementations of all

other types of SLCO statements, satisﬁes this prop-

erty. VeriFast is able to verify that all relevant vari-

ables are held by the thread executing the method cor-

responding to the implementation of the SLCO state-

ment. This implies serializability of the programs as

it an be seen from the following arguments.

Consider two instruction blocks σ and σ

which

both implement an SLCO statement. Hence, they

both contain a lock protected code block. We show

that they are serializable. Let V and V

be the set of

variables accessed by σ and σ

, respectively. Con-

sider ﬁrst the case when V ∩ V

0. Suppose that

σ ﬁrst acquires the ownership of all variables in V .

Then σ

must wait until those variables are released.

If there is some preﬁx σ

of σ

which has been ex-

ecuted before σ acquired the variables in V , then σ

could have modiﬁed only variables which are not in

V . So, this preﬁx could have been executed after σ

terminated and therefore the sequence σσ

will pro-

duce the same variable changes, i.e., the same state as

the concurrent execution of σ and σ

A similar argument can be used for the case V ∩

0. In this case the individual statements in σ

and σ

are independent of one another and can be per-

muted in an arbitrary order. The set of possible se-

quences includes both σσ

and σ

σ and they conﬂu-

ently lead to the same end state.

5 RELATED WORK

The detection of race condition violations in concur-

rent code using the lock mechanism has been ad-

dressed by a number of type-based (Farzan and Mad-

husudan, 2006), static (Engler and Ashcraft, 2003;

Abadi et al., 2006) and dynamic analysis (Choi et al.,

2002) tools. However, as shown in (Flanagan and

Qadeer, 2003), a code block free of race conditions

may still contain errors caused by simultaneous ac-

cess to shared objects. Therefore, stronger concepts

of non-interference are needed. In (Flanagan and

Qadeer, 2003), a relaxed deﬁnition of atomicity was

used and an atomic type system was implemented

to check it. The tool DoubleChecker (Biswas et al.,

2014) checks for serializability of concurrent pro-

grams based on run-time information about the de-

pendences between threads. The above mentioned

works check the correctness of programs a posteri-

ori, i.e., after they have been fully implemented. In

contrast, our approach statically veriﬁes generic code

to be used in the construction of complete programs.

There exists a substantial amount of work that

deals with model-to-code transformations. For an

overview, see (Rahim and Whittle, 2013). Here we

focus on relevant work that deals with model-to-code

transformations and uses veriﬁcation based on deduc-

tive methods, like theorem proving.

In (Blech et al., 2005), a formal veriﬁcation using

Isabelle/HOL theorem prover is presented of a con-

crete algorithm that generates Java code from UML

Statecharts. It is shown that the source UML model

and the generated Java code are bisimilar. This is a

one stage model transformation. In (Stenzel et al.,

2011), a Java code generation framework is presented.

The framework is based on the transformation lan-

guage QVT. The theorem prover KIV is used to prove

security properties and syntactic correctness. In both

these works, one of the major concerns is the scala-

bility when the transformations are applied on com-

plex models. By splitting the transformation into pro-

ducing generic and speciﬁc code, and verifying the

generic concepts in isolation, we aim to have a more

scalable approach.

Finally, software model checking techniques,

e.g., (Chaki et al., 2003; Jhala and Majumdar, 2009),

offer a supporting approach to verify code result-

ing from model-to-code transformations. These tech-

niques could in particular be useful to verify the

generic code. Tools like Java PathFinder (Visser et al.,

2003) are natural candidates for this task. It remains

to be investigated how feasible it is to apply these

techniques in a modular approach like ours, in which

each transformed concept is veriﬁed separately.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

586

6 CONCLUSIONS

We have presented an approach for the veriﬁcation of

atomicity preservation in model-to-code transforma-

tions based on separation logic using the tool Veri-

Fast. We applied this approach in the transformation

from the domain speciﬁc language SLCO to Java.

To obtain high efﬁciency, we replaced the origi-

nal strong atomicity requirement of SLCO with the

semantically relaxed notion of serializability. The

serializability was implemented by a ﬁne-grained

deadlock-free ordered locking allowing true paral-

lelism with ﬁne-grained granularity. We stated the

serializability in terms of ownership of shared vari-

ables expressed by means of lock invariants. Using

VeriFast we veriﬁed the non-interference in the Java

code.

ACKNOWLEDGEMENTS

This work was done with ﬁnancial support from the

China Scholarship Council (CSC) and ARTEMIS

Joint Undertaking project EMC2 (grant agreement

621429).

REFERENCES

Abadi, M., Flanagan, C., and Freund, S. N. (2006). Types

for Safe Locking: Static Race Detection for Java.

ACM Transactions on Programming Languages and

Systems (TOPLAS), 28(2):207–255.

Authors of This Paper (2015). SLCOtoJava Model Trans-

formation and Veriﬁcation. https://drive.google .com/-

drive/u/0/folders/0B2U1DbWZemiVRVlhbElPd0Z1

NVE.

Biswas, S., Huang, J., Sengupta, A., and Bond, M. D.

(2014). DoubleChecker: Efﬁcient Sound and Precise

Atomicity Checking. In ACM SIGPLAN Notices, vol-

ume 49, pages 28–39. ACM.

Blech, J., Glesner, S., and Leitner, J. (2005). Formal Veri-

ﬁcation of Java Code Generation from UML Models.

In Fujaba Days, pages 49–56.

sna

cki, D., van den Brand, M., Huizing, C., Jacobs, B.,

Kuiper, R., Wijs, A., and Zhang, D. (2015). Veriﬁ-

cation of Atomicity Preservation in Model-To-Code

Transformations. In FACS, LNCS. Springer (accepted

for publication).

Chaki, S., Clarke, E., Groce, A., Jha, S., and Veith, H.

(2003). Modular Veriﬁcation of Software Compo-

nents in C. In ICSE, pages 385–395. IEEE.

Choi, J.-D., Lee, K., Loginov, A., O’Callahan, R., Sarkar,

V., and Sridharan, M. (2002). Efﬁcient and Pre-

cise Datarace Detection for Multithreaded Object-

Oriented Programs. In ACM SIGPLAN Notices, vol-

ume 37, pages 258–269. ACM.

Engelen, L. (2012). From Napkin Sketches To Reliable Soft-

ware. PhD thesis, Eindhoven University of Technol-

ogy.

Engler, D. and Ashcraft, K. (2003). RacerX: Effective,

Static Detection of Race Conditions and Deadlocks.

In ACM SIGOPS Operating Systems Review, vol-

ume 37, pages 237–252. ACM.

Farzan, A. and Madhusudan, P. (2006). Causal Atomic-

ity. In CAV, volume 4144 of LNCS, pages 315–328.

Springer.

Flanagan, C. and Qadeer, S. (2003). A Type and Effect Sys-

tem for Atomicity. In ACM SIGPLAN Notices, vol-

ume 38, pages 338–349. ACM.

Jacobs, B., Smans, J., Philippaerts, P., Vogels, F., Pen-

ninckx, W., and Piessens, F. (2011). VeriFast: A

Powerful, Sound, Predictable, Fast Veriﬁer for C and

Java. In NFM, volume 6617 of LNCS, pages 41–55.

Springer.

Jhala, R. and Majumdar, R. (2009). Software Model Check-

ing. ACM Computing Surveys, 41(4):21:1–21:54.

Kleppe, A., Warmer, J., and Bast, W. (2005). MDA Ex-

plained: The Model Driven Architecture(TM): Prac-

tice and Promise. Addison-Wesley Professional.

Kolovos, D., Rose, L., Garca-Dominguez, A., and Paige, R.

(2011). The Epsilon Book. Eclipse.

O’Hearn, P., Reynolds, J., and Yang, H. (2001). Local

Reasoning about Programs that Alter Data Structures.

In Computer Science Logic, 15th International Work-

shop, CSL 2001., volume 2142 of Lecture Notes in

Computer Science, pages 1–19.

Owicki, S. and Gries, D. (1976). Verifying Properties of

Parallel Programs: An Axiomatic Approach. Com-

mun. ACM, 19(5):279–285.

Rahim, L. and Whittle, J. (2013). A Survey of Approaches

for Verifying Model Transformations. Software &

Systems Modeling (available online).

Reynolds, J. C. (2002). Separation Logic: A Logic for

Shared Mutable Data Structures. In Logic in Com-

puter Science, 2002. Proceedings. 17th Annual IEEE

Symposium on, pages 55–74. IEEE.

Stenzel, K., Moebius, M., and Reif, W. (2011). Formal

Veriﬁcation of QVT Transformations for Code Gen-

eration. In MODELS, volume 6981 of LNCS, pages

533–547. Springer.

Tuerk, T. (2009). A Formalisation of Smallfoot in HOL.

In TPHOLs, volume 5674 of LNCS, pages 469–484.

Springer.

Visser, W., Havelund, K., Brat, G., Park, S., and Lerda, F.

(2003). Model Checking Programs. Automated Soft-

ware Engineering, 10(2):203–232.

Wijs, A. J. (2013). Deﬁne, Verify, Reﬁne: Correct Compo-

sition and Transformation of Concurrent System Se-

mantics. In FACS, volume 8348 of LNCS, pages 348–

368. Springer.

Wijs, A. J. and Engelen, L. J. P. (2013). Efﬁcient Prop-

erty Preservation Checking of Model Reﬁnements.

In TACAS, volume 7795 of LNCS, pages 565–579.

Springer.

Veriﬁcation of Atomicity Preservation in Model-to-Code Transformations using Generic Java Code

587

Wijs, A. J. and Engelen, L. J. P. (2014). REFINER:

Towards Formal Veriﬁcation of Model Transforma-

tions. In NFM, volume 8430 of LNCS, pages 258–263.

Springer.

Zhang, D., Bo

sna

cki, D., van den Brand, M., Engelen, L.,

Huizing, C., Kuiper, R., and Wijs, A. (2014). Towards

Veriﬁed Java Code Generation from Concurrent State

Machines. In AMT, volume 1277 of CEUR Workshop

Proc., pages 64–69. CEUR-WS.org.

MODELSWARD 2016 - 4th International Conference on Model-Driven Engineering and Software Development

588