Static analysis 23rd international symposium, SAS 2016

A store buffering litmus test sb Let’s read thelisa code; our litmus test is composed of: – a prelude at line 0:, between curly brackets, which initialises the variables F1and F2 to 0; –

123

23rd International Symposium, SAS 2016 Edinburgh, UK, September 8–10, 2016 Proceedings

Lecture Notes in Computer Science 9837Commenced Publication in 1973

Founding and Former Series Editors:

Gerhard Goos, Juris Hartmanis, and Jan van Leeuwen

Editorial Board

Friedemann Mattern, Switzerland John C Mitchell, USA

Bernhard Steffen, Germany Demetri Terzopoulos, USA

Advanced Research in Computing and Software Science Subline of Lecture Notes in Computer Science

Subline Series Editors

Giorgio Ausiello, University of Rome‘La Sapienza’, Italy

Vladimiro Sassone, University of Southampton, UK

Subline Advisory Board

Susanne Albers, TU Munich, Germany

Benjamin C Pierce, University of Pennsylvania, USA

Bernhard Steffen, University of Dortmund, Germany

Deng Xiaotie, City University of Hong Kong

Jeannette M Wing, Microsoft Research, Redmond, WA, USA

More information about this series at http://www.springer.com/series/7408

Xavier Rival (Ed.)

Static Analysis

23rd International Symposium, SAS 2016

Proceedings

123

Lecture Notes in Computer Science

ISBN 978-3-662-53412-0 ISBN 978-3-662-53413-7 (eBook)

DOI 10.1007/978-3-662-53413-7

Library of Congress Control Number: 2016950412

LNCS Sublibrary: SL2 – Programming and Software Engineering

© Springer-Verlag GmbH Germany 2016

This work is subject to copyright All rights are reserved by the Publisher, whether the whole or part of the material is concerned, speci fically the rights of translation, reprinting, reuse of illustrations, recitation, broadcasting, reproduction on micro films or in any other physical way, and transmission or information storage and retrieval, electronic adaptation, computer software, or by similar or dissimilar methodology now known or hereafter developed.

The use of general descriptive names, registered names, trademarks, service marks, etc in this publication does not imply, even in the absence of a speci fic statement, that such names are exempt from the relevant protective laws and regulations and therefore free for general use.

The publisher, the authors and the editors are safe to assume that the advice and information in this book are believed to be true and accurate at the date of publication Neither the publisher nor the authors or the editors give a warranty, express or implied, with respect to the material contained herein or for any errors or omissions that may have been made.

Printed on acid-free paper

This Springer imprint is published by Springer Nature

The registered company is Springer-Verlag GmbH Berlin Heidelberg

Static Analysis is increasingly recognized as a fundamental tool for program verication, bug detection, compiler optimization, program understanding, and softwaremaintenance The series of Static Analysis Symposia has served as the primary venuefor the presentation of theoretical, practical, and applicational advances in the area.Previous symposia were held in Saint-Malo, Munich, Seattle, Deauville, Venice,Perpignan, Los Angeles, Valencia, Kongens Lyngby, Seoul, London, Verona, SanDiego, Madrid, Paris, Santa Barbara, Pisa, Aachen, Glasgow, and Namur This volumecontains the papers presented at SAS 2016, the 23rd International Static AnalysisSymposium The conference was held on September 8–10, 2016 in Edinburgh, UK.The conference received 55 submissions, each of which was reviewed by at leastthree Program Committee members The Program Committee decided to accept 21papers, which appear in this volume As in previous years, authors of SAS submissionswere able to submit a virtual machine image with artifacts or evaluations presented inthe paper In accordance with this, 19 submissions came with an artifact Artifacts wereused as an additional source of information during the evaluation of the submissions.The Program Committee also invited four leading researchers to present invitedtalks: Jade Alglave (Microsoft Research UK), Thomas A Henzinger (IST Austria,Klosterneuburg, Austria), Fausto Spoto (University of Verona, Italy), and MartinVechev (ETH Zurich, Switzerland) We deeply thank them for accepting theinvitations

fi-SAS 2016 was collocated with the Symposium on Logic-Based Program Synthesisand Transformation (LOPSTR 2016) and the Symposium on Principles and Practice ofDeclarative Programming (PPDP 2016) and it featuredfive associated workshops: theWorkshop on Static Analysis and Systems Biology (SASB 2016) and the Workshop onTools for Automatic Program Analysis (TAPAS 2016) were held before SAS, on the7th of September; the Numerical and Symbolic Abstract Domains Workshop (NSAD2016), the Workshop on Static Analysis of Concurrent Software, and REPS AT SIXTYwere held after SAS, on the 11th of September

The work of the Program Committee and the editorial process were greatly tated by the EasyChair conference management system We are grateful to Springer forpublishing these proceedings, as they have done for all SAS meetings since 1993.Many people contributed to the success of SAS 2015 We wouldfirst like to thankthe members of the Program Committee, who worked hard at carefully reviewingpapers, holding extensive discussions during the on-line Program Committee meeting,and makingfinal selections of accepted papers and invited speakers We would alsolike to thank the additional referees enlisted by Program Committee members Wethank the Steering Committee members for their advice A special acknowledgment

facili-goes to James Cheney for leading the local organization of the conference and to theUniversity of Edinburgh for hosting the Conference Finally, we would like to thankour sponsors: Facebook, Fondation de l’ENS, and Springer.

Program Committee

Bor-Yuh Evan Chang University of Colorado Boulder, USA

Patrick Cousot New York University, USA

Vijay D’Silva Google Inc., USA

Javier Esparza Technical University of Munich, Germany

Jérôme Feret Inria/CNRS/Ecole Normale Supérieure, FrancePierre Ganty IMDEA Software Institute, Spain

Roberto Giacobazzi University of Verona, Italy

Atsushi Igarashi Kyoto University, Japan

Francesco Logozzo Facebook, USA

Roman Manevich Ben-Gurion University of the Negev, IsraelMatthieu Martel Université de Perpignan Via Domitia, FranceJan Midtgaard Technical University of Denmark, DenmarkAna Milanova Rensselaer Polytechnic Institute, USA

Mayur Naik Georgia Institute of Technology, USA

Francesco Ranzato University of Padua, Italy

Xavier Rival Inria/CNRS/Ecole Normale Supérieure, France

Francesca Scozzari Università di Chieti-Pescara, Italy

Caterina Urban ETH Zürich, Switzerland

Bow-Yaw Wang Academia Sinica, Taiwan

Kwangkeun Yi Seoul National University, South Korea

Oh, HakjooSeed, Tom

Seidl, HelmutSeladji, Yassamine

Si, XujieSingh, GagandeepStein, BennoSuwimonteerabuth,Dejvuth

Tsai, Ming-HsienWalukiewicz, IgorWerey, AlexisZhang, Xin

and Maurizio Proietti

Securing a Compiler Transformation 170Chaoqiang Deng and Kedar S Namjoshi

Exploiting Sparsity in Difference-Bound Matrices 189Graeme Gange, Jorge A Navas, Peter Schachte, Harald Søndergaard,

and Peter J Stuckey

Flow- and Context-Sensitive Points-To Analysis Using Generalized

Points-To Graphs 212Pritam M Gharat, Uday P Khedker, and Alan Mycroft

Learning a Variable-Clustering Strategy for Octagon from Labeled

Data Generated by a Static Analysis 237Kihong Heo, Hakjoo Oh, and Hongseok Yang

Static Analysis by Abstract Interpretation of the Functional Correctness

of Matrix Manipulating Programs 257Matthieu Journault and Antoine Miné

Generalized Homogeneous Polynomials for Efficient Template-Based

Nonlinear Invariant Synthesis 278Kensuke Kojima, Minoru Kinoshita, and Kohei Suenaga

On the Linear Ranking Problem for Simple Floating-Point Loops 300Fonenantsoa Maurica, Frédéric Mesnard, and Étienne Payet

Alive-FP: Automated Verification of Floating Point Based Peephole

Optimizations in LLVM 317David Menendez, Santosh Nagarakatte, and Aarti Gupta

A Parametric Abstract Domain for Lattice-Valued Regular Expressions 338Jan Midtgaard, Flemming Nielson, and Hanne Riis Nielson

Cell Morphing: From Array Programs to Array-Free Horn Clauses 361David Monniaux and Laure Gonnord

Loopy: Programmable and Formally Verified Loop Transformations 383Kedar S Namjoshi and Nimit Singhania

Abstract Interpretation of Supermodular Games 403Francesco Ranzato

Validating Numerical Semidefinite Programming Solvers

for Polynomial Invariants 424Pierre Roux, Yuen-Lam Voronin, and Sriram Sankaranarayanan

Enforcing Termination of Interprocedural Analysis 447Stefan Schulze Frielinghaus, Helmut Seidl, and Ralf Vogler

From Array Domains to Abstract Interpretation Under Store-Buffer-Based

Memory Models 469Thibault Suzanne and Antoine Miné

Making k-Object-Sensitive Pointer Analysis More Precise

with Still k-Limiting 489Tian Tan, Yue Li, and Jingling Xue

Author Index 511

Invited Papers

Simulation and Invariance for Weak Consistency

Jade Alglave1,2(B)

1 Microsoft Research Cambridge, Cambridge, UK

j.alglave@ucl.ac.uk

2 University College London, London, UK

Abstract We aim at developing correct algorithms for a wide variety of

weak consistency modelsM0, , M n Given an algorithmA and a

con-sistency modelM ∈ {M0, , M n }, at quite a high-level examining the

correctness of the algorithmA under M amounts to asking, for example,

“can these executions happen?”, or “are these the only possible tions?” Since a few years, Luc Maranget and myself have been designing

execu-and developing the herd7 simulation tool: given a litmus test, i.e a small piece of code and a consistency model, i.e a set of constraints defining

the valid executions of a program, the herd7 tool outputs all the ble executions of the litmus test under the consistency model In recentworks with Patrick Cousot, we have developed an invariance method forproving the correctness of algorithms under weak consistency models Inthis paper I would like to give a general overview of these works

Weak consistency models (WCMs) are now a fixture of computing systems: for

example Intel x86 or ARM processors, Nvidia graphics cards, programming guages such as C++ or OpenCL, or distributed systems such as Amazon AWS

lan-or Microsoft’s Azure In this context, the execution of a concurrent program nolonger is an interleaving of the instructions involved on the different processesthat constitute the program, unlike what is prescribed by Lamport’s SequentialConsistency (SC) [Lam79a]

On the contrary, semantics of programs need to take into account

possi-ble reordering of instructions on one process, or propagation delays between processes, for example due to hardware features such as store buffers and caches Different consistency semantics styles can be used to describe WCMs Oper- ational models define abstract machines in which executions of programs are sequences of transitions made to or from formal objects modelling e.g hardware features such as store buffers and caches Axiomatic models abstract away from such concrete features and describe executions as relations over events modelling e.g read or write memory accesses, and synchronisation.

Different program semantics styles can be used to describe program tions (operational, denotational, axiomatic, etc.) The approach taken by the

execu-herd7 tool, formalised later with Patrick Cousot, is as follows Computationsare described as individual traces of processes on the one hand, and anarchic

c

 Springer-Verlag GmbH Germany 2016

X Rival (Ed.): SAS 2016, LNCS 9837, pp 3–22, 2016.

con-M ∈ {con-M0, , M n }, at quite a high-level examining the correctness of the

algo-rithmA under M amounts to asking, for example, “can these executions

hap-pen?”, or “are these the only possible executions?”

A first way to try to address this question is by simply building all the possibleexecutions ofA under M and examining to what extent the subset of executions

under scrutiny (the ones which possibility we question above) is included in theset of all possible executions

Since a few years, Luc Maranget and myself have been designing and

devel-oping the herd7 simulation tool: given a litmus test, i.e a small piece of code and a consistency model, i.e a set of constraints defining the valid executions of

a program, the herd7 tool outputs all the possible executions of the litmus testunder the consistency model

Another way to try to address this question is to build invariant specifications

of the algorithm; in other words to state properties that all executions satisfy,

at all execution points Then one needs to check that these specifications indeedare invariant Once this is done one can assess whether the executions underscrutiny satisfy the specification, in which case they can well happen

In recent works with Patrick Cousot, we have developed such a method forproving the correctness of algorithms under weak consistency models

1 a description of the semantics of each thread, and

2 a description of the communications between threads

– we need to invent a specification of how the program should behave

As an illustration, we will use the classical mutual exclusion algorithm ofPeterson [Pet81] Our algorithms will be written in our Litmus Instruction SetArchitecture (lisa) language Our consistency models will be written in our catlanguage

Simulation and Invariance for Weak Consistency 5

In this section we examine, on a store buffering litmus test, the following points:

1 write the litmus test in the Litmus Instruction Set Architecture (lisa) guage of the herd7 tool; this includes:

lan-– writing a small piece of concurrent code;

– writing a question about which executions can happen;

2 build all the possible executions of the litmus test;

3 write several consistency models in the cat language;

4 examine to what extent the executions we have asked about can happen under

a certain model

We give the code of a store buffering litmus test in lisa in Fig.1 The testuses two shared variables F1 and F2 This snippet is at the heart of Peterson’salgorithm, which we will examine later; essentially F1 and F2 are flags whicheach thread uses to indicate that they would like to enter their critical sections

LISA SB{F1=0; F2=0}

w[] F1 1 | w[] F2 1 ;r[] r1 F2 | r[] r3 F1 ;exists (0:r1=0 /\ 1:r3=0)

Fig 1 A store buffering litmus test (sb)

Let’s read thelisa code; our litmus test is composed of:

– a prelude at line 0:, between curly brackets, which initialises the variables F1and F2 to 0;

– two processes P0 and P1, each depicted as a column; let’s detail the firstprocess, on the left-hand side: at line 1:, we write 1 to the variable F1—thelisa syntax for writes is “w[] x e” where x is a variable and e an expressionover registers, whose value is written to x At line 5: we read the value ofshared variable F2 and place it into register R1, which is private to the firstthread

– a question about the final state of registers R1 and R2; here we ask: “is itpossible that R1 and R2 both contain the value 0?”

This outcome is possible on machines that feature store buffers for example.

Indeed the two writes—the write of F1 on P0 and the write of F2 on P1—can bemade to the respective private store buffers of P0 and P1 Then the two reads

can be made from memory, i.e the read of F2 on P0 reads the initial value 0, and idem for the read of F1 on P1 Finally, the two writes are flushed to memory.

6 J Alglave

We now show all the possible executions of the sb litmus test, in Fig.2

Fig 2 All possible executions of the store buffering litmus test of Fig.1

At the top left-hand corner, we see an execution where the read of F1 on P1takes its value from the write of F1 by P0, hence reads the value 1 We depict

by with a read-from arrow (rf), between the write and the read of F1.

In the same execution, we see that the read of F2 on P0 takes its valuefrom the inital state We depict this by a read-from Here we have omitted theinitialisation events to F1 and F2, hence the rf arrow has a little stub at itssource, instead of a write event

At the top right-hand corner, we see an execution where the read of F1 takesits value from the initial state, whilst the read of F2 takes its value from thewrite of F2 by P1

At the bottom left-hand corner, we see an execution where both reads taketheir values from the updates: the read of F1 reads 1 as written by P0, idem forthe read of F2

Finally at the bottom right-hand corner, we see an execution where bothreads take their values from the inital state This is the execution that leads toboth registers holding the value 0 in the end, as asked by the question at thebottom of the sb litmus test in Fig.1

Now, let’s take a closer look at that last execution We reproduce it in Fig.3,with some additional information

Fig 3 The execution ofsb leading to the final state in question

Simulation and Invariance for Weak Consistency 7

In Fig.3, we have added coherence arrows Coherence relates writes to thesame variable By convention, the initialisation write of a given variable isordered in coherence before any update of that variable Thus the write of F1

by P0 appears in coherence after the initialisation write of F1, idem for F2.Now, observe that the execution in Fig.3 exhibits a cycle: 1: w[] F1 true

—po −→5: r[] R1 F2—rf^-1 −→0: w[] F2 false—co −→21: w[] F2 true

—po −→25: r[] R3 F1—rf^-1 −→0: w[] F1 false—co −→1: w[] F1 true.This is the sequence that the consistency model needs to forbid to ensure thatthis final state is never reached

Now we can examine these questions through the prism of various consistencymodels Before detailing how we write models, we give a glimpse of the catlanguage In this paper we will focus on:

– Sequential Consistency [Lam79a] (SC), where executions of a program areinterleavings of the instructions appearing on the threads of the program, and– Total Store Order [SPA94,OSS09] (TSO), which allows store buffering scenar-ios as seen in Fig.1, and is the model of Sparc TSO and x86 machines.However we note that the cat language has been used to define a variety

of models, such as IBM Power [AMT4b], ARM [AMT4b], Nvidia [ABD+15],HSA [ACM15b], C++ [BDW16], OpenCL [BDW16]

consistency models succinctly by constraining an abstraction of program tions into a candidate execution e, po, rf, IW providing

execu-– events e, giving a semantics to instructions; for example a lisa write w[] x

v yields a write event of variable x with value v Events can be (for brevitythis is not an exhaustive list):

• writes, gathered in the set W, unless they come from the prelude of the program in which case they are gathered in the set of initial writes IW;

• reads, gathered in the set R;

• fences, gathered in the set F.

– the program order po, relating accesses written in program order in the originallisa program;

– the read-from rf describing a communication between a write and a read.The language provides additional basic built-in semantics bricks:

– the relation loc relating events accessing the same variable;

– the relation ext relating events from different processes;

– operators over relations, such as intersection &, union |, inverse of a relation

^-1, closure +, cartesian product *, set difference \.

The cat user can define new relations using let, and declare constraints overrelations, such as irreflexivity or acyclicity constraints, using the eponymous

keywords irreflexive r and acyclic r (i.e irreflexive r+).

8 J Alglave

Preliminary definitions In all the models shown below we use the following

two definitions:

– we define the relation co as relating initial writes (viz., the writes from the

prelude) to the writes in the program that access the same variable In catspeak, the set of initial writes is written IW, the set of writes in the program

is W, the relation between accesses to the same variable is loc (for location)and the intersection is &;

– we define a shorthand fr (for from-read) for the sequence of relations rf^-1

and co that appears twice in the cycle in Fig.3 We refine this relation further,

to the relation fre, which is fr restricted to accesses that belong to differentprocesses—in cat speak this is denoted by the relation ext (for external)

When M is SC In cat speak, SC is modelled as in Fig.4 (see e.g [Alg10]

for an equivalence proof) The first two lines define co and fr as above Thelast line states that there cannot be a cycle in the union (depicted by |) of theprogram order po, the read-from rf, the coherence co and the from-read fr

let co = (IW*W) & loclet fr = (rf^-1;co)acyclic po | rf | co | fr as sc

Fig 4 SC incat

WhenM is TSO In cat speak, TSO is modelled as given in Fig.5 (see e.g.

[Alg10] for an equivalence proof) The first two lines define co and fr as above.Then we define a new relation po-loc, as the restriction of the programorder po to accesses relative the same variable (see the intersection with therelation loc) Next up we require the acyclicity of the union of po-loc with allthe communication relations: read-from rf, coherence co and from-read fr Wecall this acyclicity check scpv, which stands for “SC per variable” This check

is required to ensure that all the values read and written by accesses to a same

variable are reachable on SC Less formally, this enforces coherence properties, e.g that a read of a variable cannot read from a write of the same variable

appearing later on the same thread

We then define the relation ppo (for preserved program order ) as the program order po relieved from (see the setminus operator \) the write-read pairs (W*R).

Then we define the relation rfe (for external read-from) as the restriction of theread-from rf to accesses that belong to different threads (denoted by the relationext) Finally we require the acyclicity of the union of the preserved programorder, the external read-from, the coherence and the from-read relations Wecall this acyclicity check tso, as it is the main distinguishing feature of the TSOmodel (the SC per variable check appearing in most other models that we have

studied, e.g IBM Power).

Simulation and Invariance for Weak Consistency 9

let co = (IW*W) & loclet fr = (rf^-1;co)let po-loc = po & locacyclic po-loc | rf | co | fr as scpvlet ppo = po \ (W*R)

let rfe = rf & extacyclic ppo | rfe | co | fr as tso

Fig 5 TSO incat

Recall the question that we have asked about the final state: “is it possible thatR1 and R2 both contain the value false?” Recall that the consistency modelneeds to forbid the cycle given in Fig.3 to ensure that this final state is neverreached In other words, a consistency model will forbid this execution if it

ensures that the sequence po; fre; po; fre is irreflexive, i.e communications

between the two processes of sb should not be such that taking a step in programorder po, then a step of fre, landing on the other process, then a step of po,then a step of fre again, goes back to the starting point Overall this leads tothe cat specification given in Fig.15(Fig.6):

let co = (IW*W) & loclet fre = (rf^-1;co) & extirreflexive po; fre; po; fre as sb-forbid

Fig 6 A possible specification ofsb

WhenM is SC Now, note that the sequence s forbidden by sb’s specification

is also a cycle in the union of relations which the SC model of Fig.4 requires

to be acyclic, hence a contradiction: an execution containings is also forbidden

whenM is SC.

When M is TSO An execution forbidden by our specification of sb (see

Fig.15) will not be forbidden by the TSO model given in Fig.5 This is becauseany execution forbidden by our specification of sb involves a pair write-read in

program order (see the two po edges in the sequence s for example) Moreover,

the write-read pairs are explicitly removed from the tso acyclicity check given

on the last line of the TSO model of Fig.5, thus will not contribute to executionsforbidden by the model

sb The fence semantics must be defined by a cat specification (F is the set offence events) and the specification of sb must be strengthened as given in Fig.7

10 J Alglave

let fhw = (po & (_ * F)); po

let fre = (rf^-1;co) & ext

irreflexive fhw ; fre ; fhw ; fre as sb-forbid

Fig 7 A stronger specification ofsb

In this section we will examine, on Peterson’s algorithm, the following points:

1 write the algorithm in the Litmus Instruction Set Architecture (lisa) guage of the herd7 tool [AM15] Along the way, we use lisa’s special fenceinstructions, which allow to indicate between which program points (perhapssets of program points) synchronisation is needed for correctness

lan-2 state an invariant specification S invof the algorithm;

3 state an invariant communication specificationS com of the algorithm

We give the code of Peterson’s algorithm inlisa in Fig.8 The algorithm usesthree shared variables F1, F2 and T:

– two shared flags, F1 for the first process P0 (resp F2 for the second processP1), indicating that the process P0 (resp P1) wants to enter its critical section,and

– a turn T to grant priority to the other process: when T is set to 1 (resp 2),the priority is given to P0 (resp P1)

Let’s look at the process P0: P0 busy-waits before entering its critical section(see the do instruction at line 3:) until (see the while clause at line 6:) the

process P1 does not want to enter its critical section (viz., when F2=false, which

in turn means¬R1=true thanks to the read at line 4:) or if P1 has given priority

to P0 by setting turn T to 1, which in turn means that R2=1 thanks to the read

at line 5:

LISA code Let’s read it together; our algorithm is composed of:

– a prelude at line 0:, between curly brackets, which initialises the variables F1and F2 to false and the variable T to 0;

– two processes, each depicted as a column; let’s detail the first process, on theleft-hand side: at line 1: we write true to the variable F1—the lisa syntax forwrites is “w[] x e” where x is a variable and e an expression over registers,whose value is written to x At line 2 we write 2 to T At line 3: we see a

do instruction which ensures that we iterate the instructions at lines 4 and 5

until the condition expressed at line 6 (viz., R1 ∧ R2 = 1) is false At line 4:

we read the variable F2 and write its value into register R1, and at line 5: weread the variable T and write its value into register R2 At line 7: we have askip instruction, simply to signify the critical section, and at line 8: we writefalse to F1

Simulation and Invariance for Weak Consistency 11

Fig 8 Peterson algorithm inLISA

Annotations We have placed a few annotations in our lisa code, to be usedlater in invariants and proofs:

– iteration counters: each do loop, at line 3: and at line 12:, is decorated with

an iteration counter, e.g i for the first process and j for the second process.

We also decorate the line of each until clause (i.e lines 6: and 15:) with a

symbolic name (iendand jend) to represent the iteration counter when exitingthe loop

– pythia variables: each read, at lines 4 and 5 for the first process, and lines

13 and 14 for the second process, is decorated with a pythia variable Moreprecisely a read: r[] R x at line :, reading the variable x and placing its result into register R, is decorated with the pythia variable { x n  }, where  is

the line of the read in the program, x is the variable that the read is reading,andn is an instance of the iteration counter.

Our invariants use pythia variables as opposed to simply the shared variablesbecause WCMs are such that there is no notion of instantaneous value of theshared variables that the invariants could refer to Instead, we use pythia vari-ables, which give us a unique way to denote the values read during computation

Figure9 gives an invariant specification of our implementation of Peterson: thespecification states that both processes cannot be simultaneously in their criticalsections

The next step in our specification process consists in stating an invariant munication specification S com, expressing which inter-process communicationsare allowed for the algorithm A We take the reader through this process using

com-again Peterson’s algorithm as an illustration

Fig 9 Invariant specificationS invfor Peterson’s algorithm

Peterson can go wrong under WCMs Under certain WCMs, such as

x86-TSO or any weaker model, Peterson’s algorithm is incorrect (i.e does not satisfy

the specificationS invgiven above in Fig.9, that both processes cannot be taneously in their critical section)

simul-To see this, consider Fig.10 The red arrows are an informal representation

of a communication scenario where:

– on the first process (see the left-hand side), the read at line 4: reads the valuethat F2 was initialised with at line 0:, so that R1 contains false The read atline 5: reads from the update of T by the right-hand side process, so that R2contains the value 1

– on the second process, the read at line 13: reads from the initial value of F1,

so that R3 contains false; the read at line 14: reads from the left-hand sideprocess, so that R4 contains 2

Fig 10 Incorrect execution of Peterson algorithm with WCM

In this situation (which is impossible under SC), both loop exit conditionscan be true so that both processes can be simultaneously in their critical section,thus invalidating the specificationS inv

sce-nario depicted in red in Fig.10 as an invariant We write the pythia triple

Simulation and Invariance for Weak Consistency 13

pythia, x θ , v to mean that the read   : r[] R x { x θ }, or more precisely

its pythia variable x θ, takes its value v from evaluating the expression e of the

write : w[] x e, and the local invariant at  implies that e = v.

We give a communication specification for Peterson’s algorithm in Fig.11

S com ¬[∃i, j pythia0, F2 i

4, false ∧ pythia11, T i

5, 1 ∧ pythia0, F1 j

13, false ∧ pythia2, T j

14, 2]

Fig 11 A communication specification for Peterson’s algorithm

In words, our communication specification S com states that the scenario inFig.10is impossible, which in turn ensures that both processes cannot be simul-taneously in their critical section Therefore, there cannot be two iteration coun-ters i and j such that:

– the read at line 4: and ith iteration (corresponding to the pythia variableF2i4) takes its value, false, from the initialisation of the variable F2 (whichhas been made in the prelude at line 0:);

– the read at line 5: and ith iteration (corresponding to the pythia variable Ti5)takes its value, 1, from the write at line 11;

– the read at line 13 and jth iteration (corresponding to the pythia variableF1j13) takes its value, false, from the initialisation of the variable F1 (whichhas been made in the prelude at line 0:);

– the read at line 14 and jthiteration (corresponding to the pythia variable Tj14)takes its value, 2, from the write at line 2

Our method is articulated as follows—we detail each of these points in turnbelow, and show a graphical representation in Fig.12:

1 Design and specifications:

– write the algorithmA, including synchronisation markers if needed

– state an invariant specification S inv(see Sect.3.2)

– state a communication specification S com (see Sect.3.3);

2 Proofs:

– prove the correctness of the algorithm A w.r.t the invariant specification

S inv, under the communication specificationS com (see Sect.4);

– prove that the consistency modelM guarantees the communication

speci-ficationS com that we postulated for the correctness ofA (see Sect.5).Recall Fig.12; given an algorithm A (e.g Peterson’s algorithm as given in

Fig.8) and a WCMM, we first need to invent:

14 J Alglave

Fig 12 Our method

1 an invariant specificationS inv , e.g the one in Fig.9for Peterson’s algorithm;

2 a communication specificationS com , e.g Fig.11for Peterson’s algorithm.With these two specifications at hand, we can now start proving away; ourmethod is articulated as follows:

1 Conditional invariance proof S com ⇒ S inv: we need to prove that if the nications occur like prescribed byS com, then the processes satisfy the invariant

commu-S inv;

2 Inclusion proof M =⇒ S com: we need to validate the hypotheses made in thecommunication specificationS com , viz., we need to ensure that the WCM M

guarantees them

We now detail each proof in turn

Given an algorithmA, and the specifications S invandS com, we need to prove thateach process of the algorithm satisfies a given invariantS invunder the hypothesis

S com; to do so we:

1 invent a stronger invariant S ind, which is inductive;

2 prove thatS ind is indeed inductive, i.e satisfies verification conditions ing that if it is true, it stays true after one step of computation or one step

imply-of communication that satisfiesS com; effectively we proveS com ⇒ S ind

3 prove thatS indis indeed stronger thanS inv(i.e.S ind=⇒ S inv);

Simulation and Invariance for Weak Consistency 15Thus we have:

– S com ⇒ S ind, saying thatS ind is invariant for the algorithm under tion hypothesis S com;

communica-– S ind =⇒ S inv, saying that the inductive invariant S ind is stronger than theinvariantS inv

This allows us to conclude thatS com ⇒ S inv, which was our goal We nowillustrate the correctness proof process on Peterson

An inductive invariantS ind, stronger thanS invis given in Fig.13 More precisely,Fig.13gives local invariants (depicted in blue in curly brackets) for each programpoint of each process, as in the Owicki-Gries and Lamport proof methods [OG76,Lam77] Our invariants can depend on registers (both the ones local to theprocess under scrutiny, and from other processes), pythia variables and, as inLamport’s method [Lam77], on the program counter of the other processes (thusavoiding auxiliary variables [OG76]) The invariants cannot depend on sharedvariables

Fig 13 Invariants of Peterson algorithm

Let us read the local invariants for the first process of Peterson:

– line 0: simply reflects the initialisations made in the prelude, thus we have

F1=false ∧ F2=false ∧ T=0;

16 J Alglave

– at line 1: lisa assumes that all registers local to P1 (viz., R1 and R2) are initialised to 0, thus we have R1=0 ∧ R2=0—we separate the initialisation of shared variables (e.g F1, F2 and T), factored out in the prelude, and the

initialisation of local registers, which is made at the top of each concernedprocess;

– at line 2:, we have just passed a write of F1, which leaves the invariant

unchanged, thus we still have R1=0 ∧ R2=0;

– similarly at line 3:, we just passed a write of T, which leaves the invariant

unchanged, thus we still have R1=0 ∧ R2=0;

– at line 4:, we are about to enter, or have entered, a loop, whose iterations areindexed by i as indicated by the annotation after the do instruction; the loopinvariant states that:

• either we have not entered the loop yet (i=0), in which case the registers are unchanged, viz., R1=0 ∧ R2=0, or

• we have entered the loop (i>0), in which case the registers contain updated

values, more precisely updated pythia variables: for example R1=F2i−14 cates that in the i − 1 iteration of the loop, there has been, at line 4:, a

indi-read of the variable F2, resulting in the pythia variable F2i−14 being placedinto register R1;

– at line 5: we have just passed a read of the variable F2, yielding the pythiavariable F2i4: this leads to the updated local invariant R1=F2i4∧ ((i=0 ∧ R2=0)

– at line 7:, we have just exited the loop—as symbolised by the annotation

iend—thus we have met the exit condition, viz., ¬R1 ∨ R2=1; this is reflected in

the invariant ¬ F2 iend

S ind is inductive under the hypothesisS com; we prove this in several steps:

– Initialisation proof: we must prove that the invariant at the entry of each process (e.g R1=0 ∧ R2=0 for P0) is true when all processes are at their entry,

all registers hold the value 0, and there is no pythia variable;

– Sequential proof: we must prove that the invariants are true when executing

a process sequentially This is simple since:

• a read r[] R x  x i

updates the value of register R to the adequate pythiavariable xi ,

• a write is handled like a skip, i.e has no effect on the invariant, and

• loops are handled classically:

* the loop invariant at line 4: must be true upon the first loop entry (i.e R1=0 ∧ R2=0 when i=0), and

Simulation and Invariance for Weak Consistency 17

* on the ith iteration, if the invariant at line 6: is true after the previous

iteration (i.e R1=F2 i−14 ∧ R2=T i−1

5 ), and the exit condition is false (i.e.

we do not have¬F2 i−1

5 =1), then the loop invariant at line 4: must

be true for i (i.e R1=F2 i−14 ∧ R2=T i−1

5 since the registers hold the valuesread at the previous iteration), and

* if the invariant at line 6: is true at the end of the loop i.e when iend= iand the while test is false, then the invariant at line 7: must be true,

i.e ¬ F2 iend

– Absence of interference proof: we must prove that if an invariant is true at a

given program point of a process, and another process takes one step of tation, the invariant stays true In our example, the invariants of each processdepend only on its own registers and pythia variables which are not modified

compu-by the other process (the upcoming communication proof takes into accountthe fact that the pythia variables can be modified by the communications)

– Communication proof: we must prove that if an invariant is true at some

process point of a process p and a read for x θ is performed then the valuereceived into xθ is that of a matching write Of course only the communi-

cations allowed by the communication invariant S com have to be taken intoaccount

In our case, the invariants do not say anything on the value assigned to thepythia variables so that the invariants are true for any value carried by thepythia variables More precisely, the read at line 4: can read from the writes

at line 0:, 10: or 17: The invariant at line 4: does not make any distinction

on these cases and just states that some value F2i4 has been read—this valuecan be true or false—and assigned to R1 Similarly the read of T at line5: can read from the writes at line 0:, 2:, or 11: Again the invariant doesnot make any distinction between these cases just stating that some value Ti5

is read and assigned to R2 So the communications can be anarchic and theinvariance proof does not make, on that example, any use of the communica-tion hypothesisS com It is however used in the next proof, thatS indis strongerthanS inv

S ind is stronger than S inv under the hypothesis S com ; we establish our mutual exclusion proof by reductio ad absurdum More precisely, we want to prove that

(S com ∧S ind) =⇒ S inv We choose to prove the equivalent (S ind ∧¬S inv) =⇒ ¬S com

Thus we assume that at{7} and at{16} do hold and get a contradiction:

i.e the invariants at lines 7: and 16: hold

=⇒ ¬S com since by taking i = iend and j = jend, we

have F2i4= false ∧ T i5= 1∧ F1 j13 = false ∧

Tj14= 2 

18 J Alglave

Recall that we have proved that the algorithmA satisfies the invariant S invunder

a certain communication hypothesis specified byS com To ensure thatS invholds

in the context of the consistency modelM, we need to ensure that M guarantees

that the communication specificationS com holds

This is essentially an inclusion proof, that all the behaviours allowed byM

are allowed byS com, which we writeM =⇒ S com Proving thatM =⇒ S comis theonly bit of proof that must be adapted when considering a different modelM .

To make this inclusion proof easier, we translate our specificationS com intothe same language as the model M Recall that we use the cat language to

describe our modelM; hence we need to find a cat specification H cmthat passes our specificationS com

encom-We now take the reader through this process using again Peterson’s algorithm(see Fig.8) withS com being Fig.11in Sect.3.3as an illustration More precisely,

we proceed as follows:

1 we build the communication scenario corresponding to the pythia triples;

2 we write the corresponding cat specification H cm;

3 we prove that all the behaviours allowed by H cm are allowed byS com;

4 we prove that all the behaviours allowed by M are allowed by H cm

to the Pythia Triples

This requires us building several relations between accesses:

– the read-from relation rf links a write w of a variable to a read r of the same

variable, such thatr takes its value from w;

– the coherence relation co links an initial write of a variable in the prelude to

all the writes of that variable in the program;

– the program order relation po links accesses (i.e.read/write events) that appear

in program order on a process

More precisely, given the code of the algorithmA (e.g Peterson’s in Fig.8)

and an anarchic invariant (i.e.without any restriction on possible tions, e.g Peterson’s in Fig.13), we build the following relations (see Fig.14withplain or dotted arrows):

communica-– read-from rf: for each pythia triple, we depict the read-from relation in red;

for example forpythia0, F2 i

4, false, we create a read-from relation between a

write and a read of the variable F2 with value false The write comes fromline 0:, and the read from line 4, at the ith iteration

– coherence co: we depict the coherence edges relative to the variables mentioned

by the pythia triples, in our case F1, F2 and T: see in Fig.14the edge in bluebetween the write of F1 (resp F2, T) in the prelude at line 0: and the write

of F1 (resp F2, T) at line 1: (resp 10: for F2 and 2:, 11: for T)

Simulation and Invariance for Weak Consistency 19

– program order po: we also depict the program order edges between the accesses which are either the source or the target of a communication edge (viz., read-

from and coherence): see in Fig.14the po edges in purple between the lines1:, 2:, 4:, and 5: on the first process, and similarly on the second process

po is irreflexive and transitive (not represented on Fig.14)

w(start, 0:, w[] F1 false, θ0, false)

w(start, 0:, w[] F2 false, θ1, false)

Fig 14 Communications corresponding to the pythia triples for Peterson

Now in Fig.14(where dotted lines can be ignored), note the reflexive sequence1: w[] F1 true—po −→4: r[] R1 F2—rf^-1 −→0: w[] F2 false—co −→

10: w[] F2 true—po −→13: r[] R3 F1—rf^-1 −→0: w[] F1 false—co −→

1: w[] F1 true This is the sequence that our cat specification H cm will forbid

Writing the corresponding cat specification H cm goes as follows (see Fig.15forthe definition of H cm in cat):

– we define the relation co as relating initial writes (viz., the writes from the

prelude) to the writes in the program that access the same variable In catspeak, the set of initial writes is written IW, the set of writes in the program

is W, the relation between accesses to the same variable is loc (for location)and the intersection is &;

– we define a shorthand fr (for from-read) for the sequence of relations rf^-1

and co that appears twice in the cycle in Fig.14 We refine this relation

fur-ther, to the relation fre, viz fr restricted to accesses that belong to different

processes—in cat this is denoted by the relation ext (for external);

20 J Alglave

– we require the sequence po; fre; po; fre to be irreflexive, i.e

communica-tions between the two processes of Peterson should not be such that taking astep in program order po, then a step of fre, landing on the other process,then a step of po, then a step of fre again, goes back to the starting point.Overall this leads to the cat specification given in Fig.15:

let co = (IW*W) & loclet fre = (rf^-1;co) & extirreflexive po; fre; po; fre as Peterson

Fig 15 A possible specificationH cmof Peterson algorithm

This is proved contrapositively i.e ¬S com =⇒ ¬H cm By¬S com in Fig.11, we get

∃i, j pythia0, F2 i

4, false ∧ pythia11, T i

5, 1 ∧ pythia0, F1 j13, false ∧ pythia2, T j14, 2

which implies 0: w[] F2 false—rf −→4: r[] R1 F2  F2i

4 and 0: w[] F1false—rf −→13: r[] R3 F1  F1j

13 The program order yields1: w[] F1 true

—po −→4: r[] R1 F2  F2i

4 and 10: w[] F2 true— po −→13: r[] R3 F1  F1j13

By definition of the coherence order0: w[] F2 false—co −→10: w[] F2 trueand 0: w[] F1 false—co −→1: w[] F1 true It follows that reflexive po;fre; po; freis true proving ¬H cm

Now, note that the sequences forbidden by Peterson’s specification is exactly

the same as the one we examined for the sb litmus test in Section2.4 Thus allconclusions are identical, and one needs to add fences as in sb to make Petersoncorrect under TSO or weaker models

This is proved by reductio ad absurdum Suppose an execution of son that is forbidden by H cm yet allowed by M Such an execution

Peter-involves a sequence s of accesses a, b, c, d such that s = a — po −→b

M (e.g SC) or prevented by adding fences (e.g TSO).

The consistency modelM (e.g SC with fhw = no fence; TSO with fhw = mfence) must then be shown to implement H cmby the proof method of [ACM15a](Fig.16)

Simulation and Invariance for Weak Consistency 21

Fig 16 Peterson algorithm for WCM with fences

To conclude we list here a few perspectives for future work

A first perspective is to envisage verifying programs rather than algorithms

writ-ten in lisa However our theoretical developments, and to a lesser extent ourtool developments, are based onlisa and its semantics Ideally one could designand prove their algorithms in lisa, then translate the algorithms into the lan-guage of their choice, or conversely translate a program of interest into a lisaalgorithm In both cases this requires:

1 a formal comparison of the semantics of both languages, to ensure that thetranslation does not introduce any unsoundness;

2 some automation to help with fiddly translations

or the Other Way Around

Recall from Sect.5.3that we need to link our consistency hypothesisH cm, whichexpresses in cat a constraint over the communications of our algorithms, with ourcommunication specification, which morally should express the same constraintusing pythia variables

Thus a second perspective is to envisage automating the link between the two,for example producing the communication specification used in the invarianceproof from the consistency hypothesis in cat

a Consistency Hypothesis

Recall from Sect.5.4that we need to show that our consistency hypothesisH cmissatisfied under a given consistency modelM This essentially requires comparing

22 J Alglave

two cat models, and deciding to what extent they rule out the same executions

of a given program

Thus a third perspective is to envisage automating the comparison of two

cat models, e.g exhibiting a litmus test that distinguishes the two, if any.

Finally, a fourth perspective, which should feel quite natural to the SAS munity, is to envisage other kinds of proof methods and analyses, better suitedfor automation We look forward to discussing this perspective further

com-Acknowledgements We thank Luc Maranget and Patrick Cousot for the thrilling

years spent working together, hoping for many more to come We thank VincentJacques for comments on a draft

References

[ABD+15] Alglave, J., Batty, M., Donaldson, A.F., Gopalakrishnan, G., Ketema, J.,

Poetzl, D., Sorensen, T., Wickerson, J.: GPU concurrency: weak behavioursand programming assumptions In: ASPLOS (2015)

[ACM15a] Alglave, J., Cousot, P., Maranget, L.: La langue au chat:cat, a language to

describe consistency properties, 31 January 2015 Unpublished manuscript[ACM15b] Alglave, J., Cousot, P., Maranget, L.: Syntax and semantics of the cat

language HSA Foundation, Version 1.1:38 p., 16 October 2015

[Alg10] Alglave, J.: A Shared Memory Poetics Ph.D thesis, Universit´e Paris 7

[BDW16] Batty, M., Donaldson, A.F., Wickerson, J.: Overhauling SC atomics in C11

and OpenCL In: POPL (2016)

[Lam77] Lamport, L.: Proving the correctness of multiprocess programs IEEE

Trans Software Eng 3(2), 125–143 (1977)

[Lam79a] Lamport, L.: How to make a multiprocessor computer that correctly

exe-cutes multiprocess programs IEEE Trans Comput 28(9), 690–691 (1979)

[OG76] Owicki, S.S., Gries, D.: An axiomatic proof technique for parallel programs

I Acta Inf 6, 319–340 (1976)

[OSS09] Owens, S., Sarkar, S., Sewell, P.: A better x86 memory model: x86-TSO

In: Berghofer, S., Nipkow, T., Urban, C., Wenzel, M (eds.) TPHOLs 2009.LNCS, vol 5674, pp 391–407 Springer, Heidelberg (2009)

[Pet81] Peterson, G.L.: Myths about the mutual exclusion problem Inf Process

Lett 12(3), 115–116 (1981)

[SPA94] SPARC International Inc The SPARC Architecture Manual Version 9

(1994)

Quantitative Monitor Automata

Krishnendu Chatterjee1(B), Thomas A Henzinger1, and Jan Otop2

1 IST Austria, Klosterneuburg, Austriakrish.chat@gmail.com

2 University of Wroclaw, Wroclaw, Poland

Abstract In this paper we review various automata-theoretic

for-malisms for expressing quantitative properties We start with finite-stateBoolean automata that express the traditional regular properties Wethen consider weightedω-automata that can measure the average den-

sity of events, which finite-state Boolean automata cannot However, evenweighted ω-automata cannot express basic performance properties like

average response time We finally consider two formalisms of weighted

ω-automata with monitors, where the monitors are either (a) counters

or (b) weighted automata themselves We present a translation result toestablish that these two formalisms are equivalent Weightedω-automata

with monitors generalize weighted ω-automata, and can express

aver-age response time property They present a natural, robust, and sive framework for quantitative specifications, with important decidableproperties

In this work we review various automata-theoretic formalisms for ing quantitative properties We start with the motivation for quantitativeproperties.1

express-Traditional to quantitative verification The traditional formal verification

prob-lem considers Boolean or functional properties of systems, such as “every request

is eventually granted” For analysis of resource-constrained systems, such asembedded systems, or for performance analysis, quantitative properties are nec-essary Hence recently significant research activities have been devoted to quan-titative aspects such as expressing properties like “the long-run average success

This research was supported in part by the Austrian Science Fund (FWF) undergrants S11402-N23 (RiSE/SHiNE) and Z211-N23 (Wittgenstein Award), ERC Startgrant (279307: Graph Games), Vienna Science and Technology Fund (WWTF)through project ICT15-003 and by the National Science Centre (NCN), Poland undergrant 2014/15/D/ST6/04543

1 We use the term “quantitative” in a non-probabilistic sense, which assigns a tive value to each infinite run of a system, representing long-run average or maximalresponse time, or power consumption, or the like, rather than taking a probabilisticaverage over different runs

quantita-c

 Springer-Verlag GmbH Germany 2016

X Rival (Ed.): SAS 2016, LNCS 9837, pp 23–38, 2016.

24 K Chatterjee et al.

rate of an operation is at least one half” or “the long-run average (or the mal, or the accumulated) resource consumption is below a threshold”

maxi-Automata-based properties Automata have been one of the standard ways to

express specifications of system properties For example, for Boolean properties,automata provide a robust way to express allω-regular properties [28], and allformulas expressed in Linear-time Temporal Logic (LTL) can be translated tofinite-state ω-automata [26] We review in this paper various automata-basedframeworks to express quantitative properties

Natural ways for extension The first natural way to express quantitative

prop-erties is to consider automata with counters However, computational analysis

of such models quickly leads to undecidability (such as two-counter machines),

and a classical way to limit expressiveness for decidability is to consider monitor counters, i.e., the counter values do not influence the control The second app-

roach is to consider automata with weights (or weighted automata) We describebelow various approaches that explore the two above possibilities

Weighted automata over finite words The first extension of automata with

weights was considered as weighted automata over finite words, where theweights come from a semiring [22] The weighted automata framework for exam-ple can express the worst-case execution time, where every transition is labeledwith a weight that represents the instruction execution time, and the automa-ton can choose the supremum over all traces The weighted automata frameworkhas been significantly enhanced as cost register automata [2] However, both theweighted automata and the cost register automata framework are restricted tofinite words only In this work we focus on automata over infinite words

Weighted ω-automata The counterpart of weighted automata for infinite words is called weighted ω-automata (also referred to as quantitative automata in [14]) Inweightedω-automata, which extend finite automata, every transition is assigned

a rational number called a weight Hence every run gives rise to an infinitesequence of weights, which is aggregated into a single value by a value function.For non-deterministic weightedω-automata, the value of a word w is the infimum

value of all runs over w Weighted ω-automata provide a natural and flexible

framework for expressing quantitative properties [14] For example, the property

of long-run average of the ratio of requests to grants can be expressed withweighted ω-automata, but not weighted automata over finite words However,

even weightedω-automata cannot express the following basic property [18]

Example 1 Consider infinite words over {req, gra, #}, where req represents

requests, gra represents grants, and # represents idle A basic and interesting

property is the average number of #’s between a request and the ing grant, which represents the long-run average response time of the system

correspond-We consider two variants: first, when at any point at most one request can bepending, and in general, arbitrarily many requests can be pending

Weighted automata with monitors. To express quantitative properties such asaverage response time, weighted ω-automata can be extended with monitors.

Quantitative Monitor Automata 25

The monitors can be of two types: (a) counters; and (b) weighted automata overfinite words We explain the two approaches below

Automata with monitor counters Automata with monitor counters are similar

in spirit to cost register automata, but for infinite words They are automataequipped with counters At each transition, a counter can be started, termi-nated, or the value of the counter can be increased or decreased However, thetransitions do not depend on the counter values, and hence they are referred to

as monitor counters The values of the counters when they are terminated giverise to the sequence of weights A value function aggregates the infinite sequenceinto a single value Automata with one monitor counter can express the averageresponse time property with at most one request pending (in general at mostk

requests pending withk counters), which weighted ω-automata cannot.

Nested weighted automata The second way to enrich expressiveness of weighted ω-automata is to consider weighted automata over finite words as monitors This gives rise to the framework of nested weighted automata (NWA) [18] An NWA

consists of a master automaton and a set of slave automata The master ton runs over input infinite words At every transition the master can invoke aslave automaton that runs over a finite subword of the infinite word, starting

automa-at the position where the slave automautoma-aton is invoked Each slave automautoma-atonterminates after a finite number of steps and returns a value to the masterautomaton Each slave automaton is equipped with a value function for finitewords, and the master automaton aggregates the returned values from slaveautomata using a value function for infinite words In other words, the slaveautomata are weighted automata over finite words, whereas the master automa-ton is an weightedω-automaton For Boolean finite automata, nested automata

are equivalent to the non-nested counterpart, whereas NWA are strictly moreexpressive than non-nested weighted ω-automata [18], for example, NWA canexpress the long-run average response time property (see [18, Example 5]) TheNWA framework provides a specification framework where many basic quan-titative properties, that cannot be expressed by weighted ω-automata, can be

expressed easily, and it provides a natural framework to study quantitative time verification (see [18, Sect 5]) NWA can express the average response timeproperty with any number of requests pending

run-The relationship We establish a close relationship between NWA and automata

with monitor counters More precisely, we show that automata with monitorcounters form a special class of NWA An NWA has width k if at any point

at most k slave automata can be active An NWA with bounded width is an

automaton that has width at most k, for some k We show that the class of

automata with monitor counters exactly coincides with the class of NWA withbounded width Thus the two different ways of adding monitors to weighted

ω-automata coincide and give a robust formalism for quantitative specifications.

Note that NWA in general allow to have unbounded number of monitor counters,and are more interesting as a theoretical framework, and also more challenging

to establish decidability results

26 K Chatterjee et al.

Decidability results Finally, several interesting computational problems for NWA

are decidable [18] For example, for a subclass of NWA that can express theaverage response time property, the fundamental automata theoretic questions

of emptiness and universality are decidable [18, Theorem 15]

Summary In summary, NWA provide a natural, expressive, and robust

specifica-tion framework for quantitative properties: it is a natural extension of weighted

ω-automata with nesting, which can express basic performance properties such

as average response time, and robust since two different formalisms of tors lead to the same expressive power Moreover, it enjoys nice computationalaspects, such as decidability of the basic questions A pictorial description of thelandscape of the various automata theoretic formalisms to express quantitativeproperties is shown in Fig.1

Fig 1 An overview of the automata models discussed in this paper The arrows are

labeled with a new feature introduced by a more general model, i.e., assigning values towords (weight extension), allowing infinite words (ω-extension), allowing counter moni-

tors (register extension), allowing nesting (nesting extension), and allowing unboundednumber of monitors (unbounded extension)

Related works While in this work we focus on weighted automata for infinite

words, we briefly mention the other related works Weighted automata overfinite words (see the book [22] for an excellent collection of results) as well as

Quantitative Monitor Automata 27

infinite words without monitors [13,14,23] have been extensively studied Theextension to weighted automata with monitor counters over finite words hasbeen considered as cost register automata in [2] A version of NWA over finitewords has been studied in [6] NWA over infinite words were introduced in [18].NWA with bounded width have been studied in [16] Several quantitative logicshave also been studied, such as [1,5,7] While we will consider the basic decisionproblems of emptiness and universality for weighted ω-automata, the study of

quantitative properties on other models (such as probabilistic models) or othersemantics (like probabilistic semantics) have also been studied extensively [3,4,

8 11,15,17,19,20,24,25,27]

In this section we consider Boolean finite-state automata to express qualitative(i.e., functional or regular) properties

or infinite) sequence of letters from Σ We denote the i-th letter of a word w

by w[i] The length of a finite word w is denoted by |w|; and the length of an

infinite wordw is |w| = ∞.

alphabet, (2) Q is a finite set of states, (3) Q0 ⊆ Q is the set of initial states,

(4)δ ⊆ Q × Σ × Q is a transition relation, and (5) F is a set of accepting states,

An automatonΣ, Q, q0, δ, F  is deterministic if and only if δ is a function from

Q × Σ into Q and Q0 is a singleton In definitions of deterministic automata weomit curly brackets in the description ofQ0 and writeΣ, Q, q0, δ, F .

of states ofA of length |w|+1 such that π[0] belong to the initial states of A and

for every 0≤ i ≤ |w| − 1 we have (π[i], w[i], π[i + 1]) is a transition of A A run π

on a finite wordw is accepting iff the last state π[|w|] of the run is an accepting

state of A A run π on an infinite word w is accepting iff some accepting state

of A occurs infinitely often in π For an automaton A and a word w, we define Acc(w) as the set of accepting runs on w Finally, we define a language recognized

by an automatonA as the set of words w such that Acc(w) = ∅.

Example 2 (Responsiveness) We consider a system with three types of events:

requests (req), grants (gra) and null instructions (#) We consider the following

specifications express that the system is responsive:

SB1 G(req → ¬reqUgra): requests and grants are organized in non-overlapping

pairs

SB2 G(req → Fgra): every request is followed by a grant,

SB3 GFreq → GFgra: if infinite number of request is issued, the system issues

infinitely many grants

28 K Chatterjee et al.

The above properties are ordered from the strongest to the weakest, i.e., thefirst property implies the second and the second implies the third The converseimplications do not hold

Every LTL formulaϕ can be translated to a B¨uchi automaton, which

recog-nize words satisfying ϕ In particular, properties SB1, SB2 and SB3 can be

expressed by automata presented in Fig.2

Fig 2 Finite-state automata expressing properties SB1, SB2 and SB3 Double circles

denote accepting states, the state the most to the left is an initial state and∗ denotes

all lettersreq, gra, #.

Results A basic question for automata is the language emptiness (resp.,

univer-sality) problem that asks whether there exists a word that is accepted (resp., allwords are accepted) The emptiness problem is NLOGSPACE-complete whereasthe universality problem is PSPACE-complete [28]

In this section we present weighted automata over finite words and infinite words

We call weighted automata over infinite words as weighted ω-automata (which was originally called quantitative automata [14]) For brevity, if it is clear from the

context that we consider infinite words, then we simply use weighted automatainstead of weightedω-automata These automata assign numbers to words, and hence can express quantitative properties such as workload of a system The

following definitions are common for finite- and infinite-word automata

extended by a functionC assigning elements of X to transitions of A Formally, X-labeled automaton A is a tuple Σ, Q, Q0, δ, F, C, where Σ, Q, Q0, δ, F  is

an automaton and

Z is the set of integers The labels are called weights.

Semantics of weighted automata We define the semantics of weighted

automata in two steps First, we define the value of a run Second, we definethe value of a word based on the values of its runs To define values of runs, we

will consider value functions f that assign real numbers to sequences of integers.

Quantitative Monitor Automata 29

Given a non-empty wordw, every run π of A on w defines a sequence of weights

of successive transitions of A, i.e., C(π) = (C(π[i − 1], w[i], π[i]))1≤i≤|w|; and

the value f(π) of the run π is defined as f(C(π)) We denote by (C(π))[i] the

weight of thei-th transition, i.e., C(π[i−1], w[i], π[i]) The value of a non-empty

wordw assigned by the automaton A, denoted by L A(w), is the infimum of the set of values of all accepting runs; i.e., inf π∈Acc(w) f(π), and we have the usual

semantics that the infimum of an empty set is infinite, i.e., the value of a wordthat has no accepting run is infinite Every runπ on an empty word has length

1 and the sequenceC(π) is empty, hence we define the value f(π) as an external

(not a real number) value ⊥ Thus, the value of the empty word is either ⊥, if

the empty word is accepted byA, or ∞ otherwise To indicate a particular value

functionf that defines the semantics, we will call a weighted automaton A an f-automaton.

Value functions We will consider the classical functions and their natural

vari-ants for value functions For finite runs we consider the following value functions:for runs of lengthn + 1 we have

1 Max and min: Max( π) = max n

i=1(C(π))[i] and Min(π) = min n

i=1(C(π))[i].

2 Sum and absolute sum: the sum function Sum( π) =n i=1(C(π))[i] and the

absolute sum Sum+(π) =n i=1 Abs((C(π))[i]), where Abs(x) is the absolute

value ofx.

We denote the above class of value functions for finite words as FinVal =

{Max, Min, Sum, Sum+} For infinite runs we consider:

1 Supremum and Infimum, and Limit supremum and Limit infimum: Sup( π) =

sup{(C(π))[i] : i > 0}, Inf(π) = inf{(C(π))[i] : i > 0}, LimSup(π) =

lim sup{(C(π))[i] : i > 0}, and LimInf(π) = lim inf{(C(π))[i] : i > 0}.

2 Limit average: LimAvg( π) = lim sup

k→∞

1

k ·k i=1(C(π))[i].

We denote the above class of value functions for infinite words as InfVal =

{Sup, Inf, LimSup, LimInf, LimAvg}.

Example 3 (Workload) Recall the setting of requests and grants from Example2and properties regarding responsiveness of the system However, property 1 issatisfied by a tracereqgrareq2gra req i gra in which the average number of

requests per grant tends to infinity Property1implies the long-time average ofrequests per grant is 1, but it is much stronger as it requires a pending request

to be matched with a grant before a new request can be issued With

LimAvg-automata we can specify the workload of the system, which is defined as the

long-term average of difference between requests and grants

Results The classical decision questions for automata, emptiness and

universal-ity have their counterparts in the quantitative framework The emptiness (resp.,universality) problem that asks, given a weighted automaton and a threshold,whether there exists a word whose value does not exceed the threshold (resp., val-ues of all words do not exceed the threshold) The complexity of these problems

30 K Chatterjee et al.

depends on the value function For the finite words, a comprehensive account ofthe results is available in [22] Below we discuss the results for infinite words.For the considered values functions, the emptiness problem is in PTIME [14,Theorem 3], whereas complexity of the universality problem ranges betweenPSPACE-complete [14, Theorem 7] and undecidable ([12, Theorem 5] which fol-lows from [21, Theorem 4])

In this section we consider automata with monitor counters, which extendweightedω-automata.

Am-c is a tuple Σ, Q, Q0, δ, F  where (1) Σ is the alphabet, (2) Q is a finite

set of states, (3) Q0 ⊆ Q0 is the set of initial states, (4) δ is a finite subset of

Q × Σ × Q × (Z ∪ {s, t}) n called a transition relation, (each component refers

to one monitor counter, where letters s, t refer to starting and terminating the

counter, respectively, and the value from Z is the value that is added to thecounter), and (5) F is the set of accepting states Moreover, we assume that

for every (q, a, q  , u) ∈ δ, at most one component in u contains s, i.e., at most

one counter is activated at each position Intuitively, the automaton Am-c isequipped withn counters The transitions of Am-c do not depend on the values

of counters (hence, we call them monitor counters); and every transition is of theform (q, a, q  , v), which means that if Am-cis in the stateq and the current letter

isa, then it can move to the state q  and update counters according tov Each

counter is initially inactive It is activated by the instruction s, and it changes

its value at every step by adding the value between−N and N until termination

t The value of the counter at the time it is terminated is then assigned to the

position where it has been activated An automaton with monitor countersAm-c

is deterministic if and only if Q0 is a singleton and δ is a function from Q × Σ

intoQ × (Z ∪ {s, t}) n.

fromQ×(Z×{⊥}) n is a run of Am-con a wordw if (1) π[0] = q0, ⊥ and q0∈ Q0

and (2) for every i > 0, if π[i − 1] = q, u and π[i] = q  , u   then Am-c has atransition (q, w[i], q  , v) and for every j ∈ [1, n] we have (a) if v[j] = s, then u[j] =

⊥ and u [j] = 0, (b) if v[j] = t, then u[j] ∈ Z and u [j] = ⊥, and (c) if v[j] ∈ Z,

thenu [j] = u[j]+v[j] A run π is accepting if some state from F occurs infinitely

often on the first component of π, infinitely often some counter is activated

and every activated counter is finally terminated An accepting runπ defines a

sequence π W of integers and⊥ as follows: let the counter started at position i

bej, and let the value of the counter j terminated at the earliest position after

i be x j, then π W[i] is x j The semantics of automata with monitor counters is

given, similarly to weightedω-automata, by applying the value function to π W.

More general counter operations In our framework, the counter operations

we allow are: activation, adding an integer, and termination More generally,

Quantitative Monitor Automata 31

we can allow other operations such as terminating a counter and discarding itsvalue, or adding the value of one counter to another and terminating it Theseoperations are similar in spirit to the operations on registers with the copylessrestriction in the cost register automata [2] In [2] it has been shown that thecopyless sum of registers can be eliminated using a variant of the subset construc-tion We can apply this construction to our framework, and this more generaloperations do not add expressive power as compared to the basic operationsthat we consider Hence for simplicity, and ease of establishing equivalence withother models, we consider the basic and fundamental set of counter operationsfor automata with monitor counters

(a,1,-1)

(#,0,0)(a,-1,1)

(#,t,t)

Fig 3 The automaton Adiffcomputing the maximal difference between the lengths ofblocks ofa’s at odd and the following even positions.

Example 4 (Blocks difference [16]) Consider an alphabetΣ = {a, #} and a

lan-guageL of words (#2a ∗#a ∗#)ω On the words fromL we consider a quantitative

property “the maximal block-length difference between odd and even positions”,i.e., the value of word #2a m[1]#a m[2]#3 is sup0≤i |m[2 ∗ i + 1] − m[2 ∗ i + 2]|.

This property can be expressed by a Sup-automaton Adiff with two monitorcounters depicted in Fig.3

The automaton Adiff has a single initial state q0, which is also the onlyaccepting state It processes the wordw in subwords #2a k#a m# in the following

way First, it reads #2 upon which it takes transitions fromq0toq1and fromq1

to q2, where it starts counters 1 and 2 Next, it moves to the state q2 where itcounts lettersa incrementing counter 1 and decrementing counter 2 Then, upon

reading #, it moves toq3, where it counts lettersa, but it decrements counter 1

and increments counter 2 After reading #2a k#a mthe value of counter 1 isk−m

and counter 2 ism − k In the following transition from q3toq0, the automatonterminates both counters The aggregating function of Adiff is Sup, thus theautomaton discards the lower value, i.e., the value of #2a k#a m# is|k − m| and

the automaton computes the supremum over values of all blocks It follows thatthe value of #2a m[1]#a m[2]#3 is sup0≤i |m[2 ∗ i + 1] − m[2 ∗ i + 2]|.

Example 5 ((Well-matched) average response time) Consider a system from

Examples2and3and assume that it satisfies property SB1, i.e., at every positionthere is at most one pending request Then, an automaton with a single monitorcounter can compute the average response time (ART) property, which asks forthe long-run average over requests of the number of steps between a requestand the following grant E.g ART of the trace (req##grareq#gra) ω is 1.5.