arXiv:1104.2293v1 [cs.PL] 12 Apr 2011 Languages aeoisadSbetDescriptors Subject and Categories practice. in efficient is approach proposed the that ing mechanisms, communication subject/observer self-adjust and as putation such approaches language-centric to as well is implementation our to of pared performance The repair. structure pattern scenar design reactive observer computation, to incremental applications cluding relevant conven and in idioms coding efficiently discus We it compilers. off-the-shelf implement using techniq platforms to our tional how of showing embodiment C/C++, concrete into for a a describe provide We and objects. semantics modifying and reading of for operations elementary language of tra semantics handled the altering is by mechanism ently solving o of constraint values the The upon spread variables. depend a variables some like of behave values program the where a letting change, in their locations time ory defining every re-executed Commands automatically structures. are primitiv straints including and language, arrays, host pointers, the in types, type legal obj “r any reactive of as approaches, be designated previous locations from memory Differently be tive”. special constraints in enforce that stored language objects imperative host the of programmer. propose the we on wit burden paper paradigms undue two this placing the combines In smoothly solver. that dataflow approach novel the to program ative xesoso irre of libraries or sy extensions P require Re however, languages. systems, procedural imperative/dataflow environment. mixed into ous their them da embedding of of by advantage changes take constraints to how to investigated long efficiently have searchers react pr c where to applications, specifying need dynamic for in objects support between natural straints provide languages Dataflow Abstract et fCmue n ytmSciences System and Computer of Dept. norfaeok rgamr a en riaycommands ordinary define can programmers framework, our In ecieIprtv rgamn ihDtflwConstraints Dataflow with Programming Imperative Reactive [email protected] Rome of University Sapienza dhoc ad ai Demetrescu Camil :Lnug osrcsadFeatures—Constraints and Constructs Language ]: rbe-pcfi hnepoaainagrtm,as algorithms, propagation change problem-specific dhoc ad aatpsfrbnigteimper- the binding for types data .. [ D.3.3 Programming ainaUiest fRome of University Sapienza common s et fCmue Science Computer of Dept. fi[email protected] u mem- put n data and , n com- ing cscan ects h host the ograms o,in- ios, ntactic rn Finocchi Irene nspar- taflow show- data e tween sheet com- revi- con- hout eac- ther mal on- ue 1 a - - au ftefis eli uoaial eacltd Rules recalculated. automatically the is updated, de- a cell is that cells first those the formula of of cell any value when a cells: specify other can on pends In user 28]. the [2, spreadsheet, dataflow spreadsheets a by of sim- embodied application and perhaps widespread versatility is constraints most their The of [38]. because plicity contexts in of methodology variety programming a powerful constraints a as Dataflow recognized “one-way”. are attribute the un temporarily hence left is isfied, equation the constraint, the outside il hr oecmo suswt efajsigcompu- self-adjusting with issues common prin- some dataflow share the ciple of modifications Implementations to environment. react their to of need programs in where propagation scenarios change all automatic pr for ground environ- control-driven, natural dataflow than a rather a viding data-driven, of indeed top is on ment running execution applications The explic- of assignments. changed memory flow is via program store the memory by the imper- itly standard which the in from model, different ative very is com- model dataflow putational the values, other of changes upon recalculated 39]. 34, sy 24, real-time [13, and tems animation, interac- multimedia of This context applications, variable. the tive in program explored a widely by been replaced has is approach cell/file where tar- a execution, of be the role and can than the development principle newer software dataflow to be The applied rebuilt. to also is discovered target any is the if then rule run, get, is a makefile in the file When the input files. of rebuilding input list for the a commands from and shell target file provides target and a files, between input dependency a up sets rule satmtclyr-vlae n sindt h variable the to assigned and y re-evaluated automatically is n-a,dtflwcntan sa qaino h form the of equation an is y constraint dataflow one-way, A Introduction 1. repair. structure data co pattern, design incremental observer solving, tion, constraint programming, perative Keywords Terms General makefile hnvrayvariable any whenever = ic h auso rga aibe r automatically are variables program of values the Since f ( x 1 x , . . . , eciepormig aao rgamn,im- programming, dataflow programming, Reactive r nte xml fdtflwcntans a constraints: dataflow of example another are loihs ein xeietto,languages. experimentation, design, Algorithms, n ) nwihtefruao h ih side right the on formula the which in et fCmue n ytmSciences System and Computer of Dept. x i ainaUiest fRome of University Sapienza [email protected] hne.If changes. nraRibichini Andrea y smdfidfrom modified is 2018/10/22 mputa- sat- o- in s- tation, in which programs respond to input changes by up- Address dereferencing: constraints are able to reference dating automatically their output [3, 4, 25]. variables indirectly via pointers. Differently from purely declarative constraints [7], data- Automatic dependency detection: constraints automatically flow constraints are expressed by means of (imperative) detect the reactive memory locations they depend on dur- methods whose execution makes a relation satisfied. This ing their evaluation, so there is no need for program- programming style is intuitive and readily accessible to a mers to explicitly declare dependencies, which are also broad range of developers [38], since the ability to smoothly allowed to vary over time. combine different paradigms in a unified framework makes it possible to take advantage of different programming styles We embodied these principles into an extension of C/C++ in the context of the same application. The problem of in- that we called DC. Our extension has exactly the same syn- tegrating imperative and dataflow programming has already tax as C/C++, but a different semantics. Our main contribu- been the focus of previous work in the context of specific tions are reflected in the organization of the paper and can application domains [11, 32–34, 38]. Previous mixed imper- be summarized as follows: ative/dataflow systems are based on libraries of ad hoc data types and functions for representing constraint variables and • In Section 2 we abstract our mechanism showing how for binding the imperative program to the constraint solver. to extend an elementary imperative language to support One drawback of these approaches is that constraint vari- one-way dataflow constraints using reactive memory. We ables can only be of special data types provided by the run- distinguish between three main execution modes: nor- time library, causing loss of flexibility and placing undue mal, constraint, and scheduling. We formally describe burden on the programmer.A natural question is whether the our mixed imperative/dataflow computational model by dataflow model can be made to work with general-purpose, defining the interactions between these modes and pro- imperative languages, such as C, without adding syntactic viding a formal semantics of our mechanism. extensions and ad hoc data types. In this paper we affirma- • In Section 3 we discuss convergence of the dataflow con- tively answer this question. straint solver by modeling the computation as an iterative Our Contributions. We present a general-purpose frame- process that aims at finding a common fixpoint for the work where programmers can specify generic one-way con- current set of constraints. We identify general constraint straints between objects of arbitrary types stored in reactive properties that let the solver terminate and converge to a memory locations. Constraints are written as ordinary com- common fixpoint independently of the scheduling strat- mands of the host imperative language and can be added egy. This provides a sound unifying framework for solv- and removed dynamically at run time. Since they can change ing both acyclic and cyclic constraint systems. multiple objects within the same execution, they are multi- • In Section 4 we describe the concrete embodiment of our output. The main feature of a constraint is its sensitivity to technique into C/C++, introducing the main features of modifications of reactive objects: a constraint is automati- DC. DC has exactly the same syntax as C/C++, but oper- cally re-evaluated whenever any of the reactive locations it ations that read or modify objects have a different seman- depends on is changed, either by the imperative program, or tics. All other primitives, including creating and deleting by another constraint. A distinguishing feature of our ap- constraints and allocating and deallocating reactive mem- proach is that the whole constraint solving mechanism is ory blocks, are provided as runtime library functions. handled transparently by altering the semantics of elemen- • In Section 5 we give a variety of elementary and ad- tary operations of the host imperative language for reading vanced programming examples and discuss how DC can and modifying objects. No syntax extensions are required improve C/C++ programmability in three relevant appli- and no new primitives are needed except for adding/remov- cation scenarios: incremental computation, implementa- ing constraints, allocating/deallocating reactive memory lo- tion of the observer software design pattern, and data cations, and controlling the granularity of solver activations. structure checking and repair. To the best of our knowl- Differently from previous approaches, programmers are not edge, these applications have not been explored before in forcedto use any special data types providedby the language the context of dataflow programming. extension, and can resort to the full range of conventional constructs for accessing and manipulating objects offered by • In Section 6 we describe how DC can be implemented the host language. In addition, our framework supports all using off-the-shelf compilers on conventional platforms the other features that have been recognized to be important via a combination of runtime libraries, hardware/operat- in the design of dataflow constraint systems [38], including: ing system support, and dynamic code patching, without requiring any source code preprocessing. Arbitrary code: constraints consist of arbitrary code that is • In Section 7 we perform an extensive experimental anal- legal in the underlying imperative language, thus includ- ysis of DC in a variety of settings, showing that our im- ing loops, conditionals, function calls, and recursion. plementation is effective in practice. We consider both
2 2018/10/22 write to reactive constraint interactive applications and computationally demanding memory location termination benchmarks that manipulate lists, grids, trees, matrices, normal scheduling constraint mode mode and graphs. We assess the performances of DC against mode ⇒nc ⇒e ⇒s ⇒cc ⇒ce conventional C-based implementations as well as against S=Ø S ≠Ø competitors that can quickly react to input changes, i.e., ad hoc dynamic algorithms, incremental solutions real- Figure 2. Transitions between different execution modes. ized in CEAL [25] (a state-of-the-art C-based frame- work for self-adjusting computation), and Qt’s signal- slot implementation of the subject/observer communica- • Assignments of values to storage locations (ℓ := e). These tion mechanism [22]. commands are the basic state transformers. • Constructs for sequencing, conditional execution, and it- Related work is discussed in Section 8 and directions for eration, with the usual meaning. future research are sketched in Section 9. • Two new primitives, newcons and delcons, for adding and deleting constraints dynamically. Notice that a con- 2. Abstract Model straint in DWHILE is just an ordinary command. • An atomic block construct, begin at c end at, that To describe our approach, we consider an elementary im- executes a command c atomically so that any constraint perative language and we show how to extend it to support evaluation is deferred until the end of the block. This one-way dataflow constraints. We start from WHILE [35], an offers fine-grained control over solver activations. extremely simple language of commands including a sub- language of expressions. Although WHILE does not sup- In Section 4 we will show a direct application of the con- port many fundamental features of concrete imperative lan- cepts developed in this section to the C/C++ programming guages (including declarations, procedures, dynamic mem- languages. ory allocation, type checking, etc.), it provides all the build- ing blocks for a formal description of our mechanism, ab- 2.2 Memory Model and Execution Modes stracting away details irrelevant for our purposes. We dis- Our approach hinges upon two key notions: reactive memory cuss how to modify the semantics of WHILE to integrate a dataflow constraint solver. We call the extended language locations and constraints. Reactive memory can be read and written just like ordinary memory. However, differently from DWHILE. DWHILE is identical to WHILE except for a dif- ferent semantics and additional primitives for adding/delet- ordinary memory: ing constraints dynamically and for controlling the granular- 1. Ifa constraint c reads a reactive memory location ℓ during ity of solver activations. As we will see in Section 4, these its execution, a dependency (ℓ,c) of c from ℓ is logged in primitives can be supported in procedural languages as run- a set D of dependencies. time library functions. 2. If the value stored in a reactive memory location ℓ is changed, all constraints depending on ℓ (i.e., all con- 2.1 The DWHILE Language straints c such that (ℓ,c) ∈ D) are automatically re- The abstract syntax of DWHILE is shown in Figure 1. The executed. language distinguishes be- tween commands and ex- e ∈ Exp ::= ℓ | v | (e) | ... Point 2 states that constraints are sensitive to modifications pressions. We use c, c , of the contents of the reactive memory.Point 1 shows how to 1 c ∈ Comm ::= c as meta-variables rang- maintain dynamically the set D of dependencies needed to 2 skip | ing over the set of com- ℓ := e | trigger the appropriate constraints upon changes of reactive mands Comm, and e, e1, c1 ; c2 | memory locations. We remark that re-evaluating a constraint e2 as meta-variables rang- if e then c1 else c2 | c may completely change the set of its dependencies: prior ing over the set of ex- while e do c | to re-execution, all the old dependencies (−,c) ∈ D are pressions Exp. Canonical newcons c | discarded, and new dependencies are logged in D during the forms of expressions are delcons c | re-evaluation of c. either storage locations ℓ ∈ begin at c end at As shown in Figure 2, at any point in time the execution Loc, or storable values v Figure 1. Abstract syntax can be in one of three modes: normal execution, constraint over some arbitrary do- of DWHILE. execution, or scheduling. As we will see more formally later main V al. Expressions can in this section, different instructions (such as reading a re- be also obtained by applying to sub-expressions any primi- active memory location or assigning it with a value) may tive operations defined over domain V al (e.g., plus, minus, have different semantics depending on the current execution etc.). Commands include: mode.
3 2018/10/22 We assume eager constraint evaluation, i.e., out-of-date execution mode, and is undefined otherwise. If the sched- constraints are brought up-to-date as soon as possible. This uler were deterministic, cself may be omitted from the choice is better suited to our framework and, as previous ex- configuration, but we do not make this assumption in this perience has shown, lazy and eager evaluators typically de- paper. liver comparable performance in practice [38]. Eager eval- uation is achieved as follows. A scheduler maintains a data 2.4 Operational Semantics structure S containing constraints to be first executed or re- Most of the operational semantics of the DWHILE lan- evaluated. As an invariant property, S is guaranteed to be guage can be directly derived from the standard semantics empty during normal execution. As soon as a reactive mem- of WHILE. The most interesting aspects of our extension in- ory location ℓ is written, the scheduler queries the set D of clude reading and writing the reactive memory, adding and dependencies and adds to S all the constraints depending on deleting constraints, excuting commands atomically, and ℓ. These constraints are then run one-by-one in constraint defining the behavior of the scheduler and its interactions execution mode, and new constraints may be added to S with the other execution modes. Rules for these aspects are throughout this process. Whenever S becomes empty, nor- given in Figure 4 and are discussed below. mal execution is resumed. Let ⇒e ⊆ (Σ×Exp)×V al and ⇒c ⊆ (Σ×Comm)×Σ An exception to eager evaluation is related to atomic be the standard big-step transition relations used in the oper- blocks. The execution of an atomic block c is regarded as an ational semantics of the WHILE language [35]. Besides ⇒e uninterruptible operation: new constraints created during the and ⇒c, we use additional transition relations for expression evaluation of c are just added to S. When c terminates, for evaluation in constraint mode ( ⇒ce), command execution each reactive memory location ℓ whose value has changed, in normal mode ( ⇒nc), command execution in constraint all the constraints depending on ℓ are also added to S, and mode ( ⇒cc), and constraint solver execution in scheduling the solver is eventually activated. Constraint executions are mode ( ⇒s), as defined in Figure 3. Notice that expression uninterruptible as well. evaluation in normal mode can be carried on directly by We remark that any scheduling mechanism may be used means of transition relation ⇒e of WHILE. As discussed for selecting from S the next constraint to be evaluated: in below, relation ⇒ce is obtained by appropriately modifying this abstract model we rely on a function pick that imple- ⇒e. Similarly, relations ⇒nc and ⇒cc are obtained by ap- ments any appropriate scheduling strategy. propriately modifying ⇒c. All the rules not reported in Fig- ure 4 can be derived in a straightforward way from the cor- 2.3 Configurations responding rules in the standard semantics of WHILE [35]. A configuration of our system is a six-tuple The evaluation of a DWHILE program is started by rule Cons (ρ,a,σ,D,S,cself ) ∈ R×Bool×Σ×Dep×2 ×Cons EVAL, which initializes the atomic flag a to false and both where: the scheduling queue S and the set D of dependencies to the empty set. • R = {ρ : Loc → { normal, reactive }} is a set of store attributes, i.e., Boolean functions specifying which Writing Memory. Assigning an ordinary memory loca- memory locations are reactive. tion in normal execution mode (rule ASGN-N1) just changes the store as in the usual semantics of WHILE. This is also • Bool = {true, false} is the set of Boolean values. the case when the new value of the location to be assigned • Σ= {σ : Loc → Val} is a set of stores mapping storage equals its old value or inside an atomic block. Otherwise, if locations to storable values. the location ℓ to be assigned is reactive, the new value dif- • Cons is the set of constraints and 2Cons denotes its fers from the old one, and execution is outside atomic blocks powerset. A constraintcan be anycommandin DWHILE, (rule ASGN-N2), constraints depending on ℓ are scheduled i.e., Cons = Comm. We use different names for the in S and are evaluated one-by-one. As we will see, the tran- sake of clarity. sition relation ⇒s guarantees S to beemptyattheendof the constraint solving phase. In conformity with the atomic ex- • Loc×Cons Dep = 2 is the set of all subsets of dependen- ecution of constraints, assignment in constraint mode (rule cies of constraints from reactive locations. ASGN-C) just resorts to ordinary assignment in WHILE for Besides a store σ and its attribute ρ, a configuration includes: both normal and reactive locations. We will see in rule SOLVER-2, however, that constraints can be nevertheless • a Boolean flag a that is true inside atomic blocks and is scheduled by other constraints if their execution changes the used for deferring solver activations; contents of reactive memory locations. • the set D of dependencies, D ⊆ Loc × Cons; Reading Memory. Reading an ordinary memory location • the scheduling data structure S ⊆ Cons discussed above; in constraint execution mode (rule DEREF-C1) just evaluates • a meta-variable cself that denotes the current constraint the location to its value in the current store: this is achieved (i.e., the constraint that is being evaluated) in constraint by using transition relation ⇒e of the WHILE semantics.
4 2018/10/22 ′ ⇒⊆ (R× Σ × Comm) × Σ hρ, σ, ci ⇒hσ i ′ ⇒ce ⊆ (R× Σ × Cons × Dep × Exp) × (Dep × V al) hρ, σ, cself ,D,ei ⇒ce hD , vi Cons Cons ′ ′ ′ ⇒nc ⊆ (R× Bool × Σ × Dep × 2 × Comm) × (Σ × Dep × 2 ) hρ,a,σ,D,S,ci ⇒nc hσ , D ,S i Cons Cons ′ ′ ′ ⇒cc ⊆ (R× Σ × Dep × 2 × Cons × Comm) × (Σ × Dep × 2 ) hρ,σ,D,S,cself , ci ⇒cc hσ , D ,S i Cons ′ ′ ⇒s ⊆ (R× Σ × Dep × 2 ) × (Σ × Dep) hρ,σ,D,Si ⇒s hσ , D i
Figure 3. Transition relations for DWHILE program evaluation ( ⇒), expression evaluation in constraint mode ( ⇒ce), command execution in normal mode ( ⇒nc), command execution in constraint mode ( ⇒cc), and constraint solver execution in scheduling mode ( ⇒s).
′ ′ a = false ′ ′ ρ,a,S ⊢hσ, D, ci ⇒nc hσ , D i ρ, σ, cself ⊢hD,ei ⇒ce hD , vi σ = σ|ℓ7→v ′ where: D = ∅ ′ ′ ρ,S,c ⊢hσ,D,ℓ := ei ⇒cc hσ , D i ρ ⊢hσ, ci ⇒ σ S = ∅ self (EVAL) (ASGN-C) ′ ′ S = ∅ S = {c | (ℓ, c) ∈ D} σ ⊢ e ⇒e v σ = σ|ℓ7→v ′ ′ ′ ′′ ′ ′ σ ⊢ e ⇒e v σ = σ|ℓ7→v ρ ⊢hσ ,D,S i ⇒s hσ , D i ρ,a,D,S ⊢hσ, ℓ := ei ⇒nc σ ′′ ′ ρ,a,S ⊢hσ,D,ℓ := ei ⇒nc hσ , D i ′ ′ if ρ(ℓ)= normal or σ (ℓ)= σ(ℓ) or a = true if ρ(ℓ)= reactive and σ (ℓ) 6= σ(ℓ) and a = false (ASGN-N1) (ASGN-N2) ′ σ ⊢ ℓ ⇒e v σ ⊢ ℓ ⇒e v D = D ∪ {(ℓ, cself )} if ρ(ℓ)= normal ′ if ρ(ℓ)= reactive ρ, σ, cself , D ⊢ ℓ ⇒ce v ρ, σ, cself ⊢hD,ℓi ⇒ce hD , vi (DEREF-C1) (DEREF-C2) ′ ′ ′ ′ ′ ρ, cself ⊢hσ,D,S,ci ⇒cc hσ , D ,S i ρ,a,D ⊢hσ, S, ci ⇒nc hσ ,S i ′ ′ ′ ′ ′ if a = true ρ, cself ⊢hσ, D, S, begin at c end ati ⇒cc hσ , D ,S i ρ,a,D ⊢hσ, S, begin at c end ati ⇒nc hσ ,S i (BEGINEND-C) (BEGINEND-N1) ′ ′ ′ ′ S = ∅ a = true ρ, D ⊢ha , σ, S, ci ⇒nc hσ ,S i ′′ ′ ′ ′ ′′ ′′ ′ S = S ∪ { c | (ℓ, c) ∈ D ∧ σ(ℓ) 6= σ (ℓ) ∧ ρ(ℓ)= reactive } ρ ⊢hσ ,D,S i ⇒s hσ , D i ′′ ′ if a = false ρ,a,S ⊢hσ, D, begin at c end ati ⇒nc hσ , D i (BEGINEND-N2) ′ ′ ′ ′ ′ S = ∅ S = {c} ρ ⊢hσ,D,S i ⇒s hσ , D i S = S ∪ {c} ′ ′ if a = false ′ if a = true ρ,a,S ⊢hσ, D, newcons ci ⇒nc hσ , D i ρ,a,σ,D ⊢hS, newcons ci ⇒nc S (NEWCONS-N1) (NEWCONS-N2) ′ ′ ′ D = D \ {(−, c)} S = S \ {c} S = S ∪ {c} ′ ′ ′ ρ,a,σ ⊢hD,S, delcons ci ⇒nc hD ,S i ρ,σ,D,cself ⊢hS, newcons ci ⇒cc S (DELCONS-N) (NEWCONS-C) ′ ′ D = D \ {(−, c)} S = S \ {c} ′ ′ if S = ∅ ρ, σ, cself ⊢hD,S, delcons ci ⇒cc hD ,S i ρ ⊢hσ,D,Si ⇒s hσ, Di (DELCONS-C) (SOLVER-1)
′ ′ ′′ ′ cself = pick(S) ρ ⊢hσ, D ,S \ {cself }, cself , cself i ⇒cc hσ , D ,S i ′ ′ ′′ ′′ ′′ ′′′ D = D \ {(− , cself )} ρ ⊢hσ , D ,S i ⇒s hσ , D i where: ′′ ′ ′′ if S 6= ∅ ′′ ′′′ S = S ∪ {c | (ℓ, c) ∈ D ∧ ρ ⊢hσ,D,Si ⇒s hσ , D i ′ σ(ℓ) 6= σ (ℓ) ∧ ρ(ℓ)= reactive} (SOLVER-2)
Figure 4. DWHILE program evaluation.
5 2018/10/22 If the location ℓ to be read is reactive (rule DEREF-C2), a unit uses that port as a parameter, and from an execution new dependency of the active constraint cself from ℓ is also unit to a port if the unit assigns a value to that port. Paths added to the set D of dependencies. in a dataflow graph, which is usually acyclic, describe how data flows through the system, and the result of a compu- Executing Atomic Blocks. To execute an atomic block tation can be characterized algorithmically in terms of an in normal mode (rule BEGINEND-N2), the uninterruptible appropriate traversal of the graph (e.g., in a topological or- command c is first evaluated according to the rules defined der). This model is very effective in describing scenarios by transition ⇒ . If the content of some reactive loca- nc where data dependencies are either specified explicitly, or tion changes due to the execution of c, the solver is then can be derived statically from the program. However, in gen- activated at the end of the block. The begin at / end at eral the dataflow graph might be not known in advance or command has instead no effect when execution is already may evolve over time in a manner that may be difficult to atomic, i.e., in constraint mode (rule BEGINEND-C) and in- characterize. In all such cases, proving general properties side atomic blocks (rule BEGINEND-N1), except for execut- of programs based on the evaluation of the dataflow graph ing command c. may not be easy. A more general approach, which we fol- Creating and Deleting Constraints. In non-atomic nor- low in our work, consists of modeling dataflow constraint mal execution mode, rule NEWCONS-N1 creates a new con- solving as an iterative process that aims at finding a com- straint and triggers its first execution by resorting to ⇒s. mon fixpoint for the current set of constraints. In our con- In atomic normal execution and in constraint mode, rules text, a fixpoint is a store that satisfies simultaneously all the NEWCONS-N2 and NEWCONS-C simply add the constraint relations between reactive memory locations specified by the to the scheduling queue. Similarly, rules DELCONS-N and constraints. This provides a unifying framework for solving DELCONS-C remove the constraint from the scheduling dataflow constraint systems with both acyclic and cyclic de- queue and clean up its dependencies from D. pendencies.
Activating the Solver. Rules SOLVER-1 and SOLVER-2 specify the behavior of the scheduler, which is started by 3.1 Independence of the Scheduling Order rules ASGN-N2 and BEGINEND-N2. Rule SOLVER-1 de- In Section 2, we have assumed that the scheduling order of fines the termination of the constraint solving phase: this constraint executions is specified by a function pick given phase ends only when there are no more constraints to be as a parameter of the solver. A natural question is whether evaluated (i.e., S = ∅). Rule SOLVER-2 has an inductive there are any general properties of a set of constraints that definition. If S is not empty, function pick selects from S a let our solver terminate and converge to a common fix- new active constraint cself , which is evaluated in constraint point independently of the scheduling strategy used by func- mode after removing from D its old dependencies. The fi- tion pick. Using results from the theory of function itera- nal state (σ′′) and dependencies (D′′′) are those obtained by tions [15], we show that any arbitrary collection of inflation- applying the scheduler on the store σ′ obtained after the ex- ary one-way constraints has the desired property. This class ′′ ′′ ecution of cself and on a new set S of constraints. S is of constraints includes, for instance, any program that can be derived from S by adding any new constraints (S′) result- described in terms of an acyclic dataflow graph such as com- ing from the execution of cself along with the constraints putational circuits [6], non-circular attribute grammars [29], depending on reactive memory locations whose content has and spreadsheets [28] (see Section 3.2). We remark, how- ′′ been changed by cself . The definition of S guarantees that ever, that it is more general as it allows it to address prob- constraints can trigger other constraints (even themselves), lems that would not be solvable without cyclic dependencies even if each constraint execution is regarded as an atomic (an example is given in Section 3.3). operation and is never interrupted by the scheduler. We first provide some preliminary definitions in accor- dance with the terminology used in [7]. We model constraint 3. Convergence Properties execution as the application of functions on stores: In this section, we discuss some general properties of the constraint solving mechanism we adopt in DC, including DEFINITION 1. We denote by fc : Σ → Σ the function ′ termination, correctness, and running times. The computa- computed by a constraint c ∈ Cons, where fc(σ) = σ if ′ tion of one-way dataflow constraints (similarly to spread- hσ, ci ⇒c σ . We say that store σ ∈ Σ is a FIXPOINT for fc sheet formulas, circuits, etc.) is traditionally described in if fc(σ)= σ. the literature in terms of a bipartite directed graph called dataflow graph. In a dataflow graph, a node can model ei- To simplify the discussion, throughout this section we as- ther an execution unit (e.g., gate [6], process [23], one-way sume that constraints only operate on reactive cells and fo- constraint [38], or spreadsheet formula [28]) or an input/out- cus our attention on stores where all locations are reactive. put port of one or more units (e.g., gate port, variable, or The definition of inflationary functions assumes that a partial cell). There is an arc from a port to an execution unit if the ordering is defined on the set of stores Σ:
6 2018/10/22 DEFINITION 2 (INFLATIONARY FUNCTIONS). Let (Σ, ) be q is regular. Notice that S0 = S contains initially all func- any partial ordering over the set of stores Σ and let f : tions for which σ0 is not a fixpoint. Furthermore, Si+1 is Σ → Σ be a function on Σ. We say that f is inflationary obtained from Si by removing ci and adding at least all con- if σ f(σ) for all σ ∈ Σ. straints for which σi+1 is not a fixpoint. It remains to show that all constraints are activated at some step, i.e., they are Examples of partial orderings on Σ will be given in Sec- eventually removed from S. This can be proved by observ- tion 3.2 and in Section 3.3. A relevant property of partial ing that an inflationary function fci either leaves the store orderings in our context is the finite chain property, based unchanged, and therefore |S| decreases by one, or produces on the notion of sequence stabilization: a store σi+1 = fci (σi) strictly larger than σi, i.e., σi σi+1 DEFINITION 3 (FINITE CHAIN PROPERTY). A partial order- and σi 6= σi+1. By the finite chain property, this cannot hap- ing (Σ, ) over Σ satisfies the FINITE CHAIN PROPERTY if ev- pen indefinitely, so S eventually gets empty. Since q is regu- lar, the proof follows from Lemma 1. ✷ ery non-decreasing sequence of elements σ0 σ1 σ2 ... from Σ eventually stabilizes at some element σ in Σ, i.e., Assuming that functionsin Lemma 1 and Theorem1 are also if there exists j ≥ 0 such that σi = σ for all i ≥ j. monotonic, it is possible to prove that the solver always con- verges to the least common fixpoint, yielding deterministic To describe the store modifications due to the execution of results independently of the scheduling order. We recall that the solver, we use the notion of iteration of functions on a function f is monotonic if σ σ′ implies f(σ) f(σ′) stores. Let F = {f ,...,f }, ha ,...,a i, and σ ∈ Σ be a 1 n 1 k for all σ, σ′ ∈ Σ. finite set of functions on Σ, a sequence of indices in [1,n], and an initial store, respectively. An iteration of functions of F starting at σ is a sequence of stores hσ , σ , σ ,...i where 0 1 2 3.2 Acyclic Systems of Constraints σ0 = σ and σi = fai (σi−1) for i> 0. We say that function fai is activated at step i. Iterations of functions that lead to In this section we show that, if a system of constraints is a fixed point are called regular: acyclic, then our solver always converges deterministically to the correct result, without the need for programmers to DEFINITION 4 (REGULAR FUNCTION ITERATION). A func- prove any stabilization properties of their constraints. We tion iteration hσ0, σ1, σ2,...i is REGULAR if it satisfies the notice that this is the most common case in many appli- following property: for all f ∈ F and i ≥ 0, if σi is not a cations, and several efficient techniques can be adopted by fixpoint for f, then f is activated at some step j>i. constraint solvers to automatically detect cycles introduced Using arguments from Chapter 7 of [7], it can be proved by programming errors [38]. In particular, we prove termi- that any regular iteration of inflationary functions starting at nation of our solver on any system of constraints that models some initial store stabilizes in a finite number of steps to a a computational circuit subject to incremental changes of its common fixpoint: input. For the sake of simplicity, we focus on single-output constraints, to which any multi-output constraint can be re- LEMMA 1 (FIXPOINT). Let (Σ, ) be any partial ordering duced. over Σ satisfying the finite chain property and let F be a A circuit is a directed acyclic graph G = (V, E) with finite set of inflationary functions on Σ. Then any regular values computed at the nodes, referred to as gates [6]. Each iteration of F starting at σ eventually stabilizes at a common node u is associated with an output function gu that com- ′ ′ fixpoint σ of the functions in F such that σ σ . putes a value val(u) = gu(val(v1), ..., val(vdu )), where du is the indegree of node u and, for each i ∈ [1, du], arc We can now discuss convergence properties of our solver: (vi,u) ∈ E. Arcs entering u are ordered and, if du = 0, u is called an input gate (in this case, gu is constant). The THEOREM 1. Let C = {c1,...,ch} be any set of con- gate values and functions may have any data types. For sim- straints, let F = {fc1 ,...,fch } be the functions computed by constraints in C, and let (Σ, ) be any partial ordering plicity, we will assume that there is only one gate in the over Σ satisfying the finite chain property. If functions in F graph with outdegree 0: the value computed at this gate is are inflationary on Σ and {f ∈ F | f(σ) 6= σ} ⊆ S ⊆ F , the output of the circuit. The circuit value problem is to up- ′ ′ ′ date the output of the circuit whenever the value of an input then hρ,σ,D,Si ⇒s hσ ,D i and σ is a common fixpoint of the functions in F such that σ σ′. gate is changed. This problem is equivalent to the scenario where the gate values val(u) are reactive memory cells, and PROOF (SKETCH). Consider the sequence hS0,S1,...i of each non-input gate u is computed by a constraint cu that scheduling sets resulting from a recursive application of rule assigns val(u) with gu(val(v1), ..., val(vdu )). A circuit up- SOLVER-2 terminated by rule SOLVER-1 (see Figure 4), date operation changes the value val(u) of any input gate u with S0 = S. Let ci = pick(Si) the constraint executed to a new constant. Any such update triggers the solver with ′ at step i, and let q = hσ0, σ1, σ2,...i be the function itera- S = {cu′ | (u,u ) ∈ E}. We now show that the solver up- tion such that σ0 = σ and σi+1 = fci (σi). We prove that dates correctly the circuit output.
7 2018/10/22 Let n be the numberof circuit nodes,and let u1,u2, ..., un insert(u,v,w): be any topological ordering of the nodes, where un is the E := E ∪ {(u, v)} output gate of the circuit. Let σ ∈ Σ be a store with w(u, v) := w newcons( if d[u]+ w(u, v) < d[v] then d[v] := d[u]+ w(u, v) ) dom(σ) = {val(ui) | i ∈ [1,n]}. We say that a value | {z } cuv val(ui) is incorrect in σ if σ is not a fixpoint for cui . Let decrease(u,v,δ): n i b(σ)= Pi=1 2 ·χσ(ui), where χσ(ui)=1 if value val(ui) w(u, v) := w(u, v) − δ is incorrect in σ, and 0 otherwise. We define a partial order- ing (Σ, ) as follows: Figure 5. Incremental shortest path updates in a mixed im- perative/dataflow style. ′ DEFINITION 5. For any two stores σ and σ in Σ, we say ′ ′ that σ σ if b(σ) ≥ b(σ ). Incremental Shortest Paths. Let G = (V,E,w) be a di- rected graph with real edge weights w(u, v), and let s be a Relation is clearly reflexive, antisymmetric, and transitive. source node in V . We consider the incremental shortest path Moreover, the constraints cu compute inflationary functions problem that consists of updating the distances of all ′ d[u] on Σ. Let σ = fcu (σ) be obtained by evaluating contraint nodes u ∈ V from the source s after inserting any new edge cu in store σ. If val(u) is correct in σ (i.e., χσ(u)=0), then in the graph, or decreasing the weight of any existing edge. ′ σ = σ. Otherwise, χσ(u)=1, χσ′ (u)=0, and χσ(ˆu) = For the sake of simplicity we assume that no negative-weight χσ′ (ˆu) for all gates uˆ that precede u in the topological cycles are introduced by the update and that, if a node u is ordering. This implies that b(σ) ≥ b(fcu (σ)), and thus unreachable from the source, its distance d[u] is +∞. n σ fcu (σ). Since b(·) can assume only 2 possible values, (Σ, ) also satisfies the finite chain property. After updating Update Algorithm. The incremental shortest path problem an input gate u, all constraints for which σ is no longer a can be solved in our framework as follows. We keep edge ′ fixpoint are included in the set S = {cu′ | (u,u ) ∈ E} weights and distances in reactive memory. Assuming to start on which the solver is started. Hence, all the hypotheses of from a graph with no edges, we initialize d[s] := 0 and Theorem 1 hold and the solver converges to store σ′ ∈ Σ d[u] := +∞ for all u 6= s. The pseudocode of update ′ that is a common fixpoint of all fcu , i.e., a store σ in operations that insert a new edge and decrease the weight which all gate values are correct. This implies that the circuit of an existing edge by a positive amount δ are shown in output is also correct. It is not difficult to prove that, if we Figure 5. Operation insert(u,v,w) adds edge (u, v) to the let function pick(S) return constraints in topological order, graph with weight w and creates a new constraint cuv for the then all gates that may be affected by the input change are edge: cuv simply relaxes the edge if Bellman’s inequality evaluated exactly once during the update. d[u] + w(u, v) ≥ d[v] is violated [8]. The constraint is immediately executed after creation (see rule NEWCONS- 3.3 Cyclic Systems of Constraints: an Example N1 in Figure 4) and the three pairs (d[u],cuv), (d[v],cuv), and (w(u, v),cuv ) are added to the set of dependencies D. Differently from previous approaches to solving one-way Any later change to d[u], d[v] or w(u, v), which may violate dataflow constraints [6, 17, 26, 27], which were targeted to the inequality d[u] + w(u, v) ≥ d[v], will cause the re- acyclic dependencies, our abstract machine can handle the execution of cuv. Decreasing the weight of an existing edge most general case of cyclic constraints embedded within an (u, v) by any positive constant δ with decrease(u,v,δ) can imperative program. This opens up the possibility to address be done by just updating w(u, v). In view of rule ASGN-N2 problems that would not be solvable using acyclic dataflow of Figure 4, the system reacts to the change and re-executes graphs, backed up with a formal machinery to help designers automatically cuv and any other affected constraints. prove their convergence properties (Section 3.1). We exem- Using the machinery developed in Section 3.1 and suit- plify this concept by considering the well known problem ably defining a partial order on Σ and an appropriate pick of maintaining distances in a graph subject to local changes function, we now show that our solver finds a correct so- to its nodes or arcs. In the remainder of this section we lution within the best known worst-case time bounds for the show how to specify an incremental variant of the classical problem, i.e., it updates distances correctly after any insert Bellman-Ford’s single-source shortest path algorithm [8] in or decrease operation. terms of a (possibly cyclic) system of one-way constraints. Compared to purely imperative specifications [18], the for- Termination and Correctness. For the sake of conve- mulation of the incremental algorithm in our mixed impera- nience, we denote by dσ[u] = σ(d[u]) and by wσ(u, v) = tive/dataflow framework is surprisingly simple and requires σ(w(u, v)) the distance of node u and the weight of edge just a few lines of code. By suitably defining a partial order (u, v) in store σ, respectively. For any two graphs G1 and G2 on Σ and an appropriate pick function, we show that our on the same vertex set, we denote by G1 ⊎G2 the multigraph solver finds a correct solution within the best known worst- with vertex set V and edge set E1 ⊎ E1, where ⊎ indicates case time bounds for the problem. the join of multisets: the same edge may thus appear twice
8 2018/10/22 in E1 ⊎ E2, possibly with different weights. Let us focus our typedef void (*cons_t)(void*); attention on a restricted set of stores, which encompasses all int newcons(cons_t cons, void* param); possible configurations of the reactive memory during the void delcons(int cons_id); execution of the solver triggered by an update: void* rmalloc(size_t size); void rfree(void* ptr); void begin_at(); DEFINITION 6. Let Gold = (V, Eold, wold) and G = void end_at(); (V,E,w) be the graph before and after inserting a new void arm_final(int cons_id, cons_t final); edge or decreasing the weight of an edge, respectively. We void set_comp(int (*comp)(void*, void*)); denote by Σ ⊆ Σ the set of all functions σ : Loc → V al sp Figure 6. Main functions of the DC language extension. such that: • dom(σ) = {d[u] | u ∈ V }∪{w(u, v) | (u, v) ∈ E} ⊆ per operation, then the solver updates distances incremen- Loc; tally in O(m log n) worst-case time, even in the presence of • for each , is the weight of a simple path (i.e., u ∈ V dσ[u] negative edge weights (but no negative cycles). This can be with no repeated nodes) from s to u in G ⊎ G; old reduced to O(m + n log n) by just creating one constraint • for each (u, v) ∈ E, wσ(u, v) is fixed as the weight of per node, rather that one constraint per edge, and letting it edge (u, v) in G. relax all outgoing edges. This matches the best known al- Notice that, as simple paths in a graph are finite, the number gorithmic bounds for the problem [18]. We remark that, re- of possible values each dσ[u] can attain is finite, and there- computing distances from scratch with the best known static fore Σsp is a finite set. We define a partial ordering (Σsp, ) algorithm would require O(mn) time in the worst case if on Σsp as follows: there are negative edge weights, and O(m + n log n) time ′ otherwise. In Section 7.3 we will analyze experimentally the DEFINITION 7. Let σ and σ be any two stores in Σsp. We ′ performances of our constraint-based approach showing that say that σ σ if dσ[u] ≥ dσ′ [u] for all u ∈ V . in practice it can be orders of magnitude faster than recom- Relation is reflexive, antisymmetric, and transitive. More- puting from scratch, even when all weights are non-negative. over, since Σsp is finite, (Σsp, ) satisfies the finite chain property. We now prove that constraints cuv compute infla- 4. Embodiment into C/C++ tionary functions on Σsp. In this section we show how to apply the concepts devel- oped in Section 2 to the C and C++ languages, deriving an LEMMA 2. Functions f uv computed by constraints c of c uv extension that we call DC. DC has exactly the same syntax Figure 5 are inflationary with respect to the partial ordering as C/C++, but operations that read or modify objects have (Σ , ) of Definition 7. sp a different semantics. All other primitives, including creat- PROOF. Let (u, v) be any edge in E and let σ be any store ing/deleting constraints, allocating/deallocating reactive ob- in Σsp. If σ = fcuv (σ) then clearly σ fcuv (σ). Con- jects, and opening/closing atomic blocks, are provided as 1 sider the case σ 6= fcuv (σ). Notice that σ and fcuv (σ) runtime library functions (see Figure 6). can only differ in the value of memory location d[v]. Since Reactive Memory Allocation. Similarly to other automatic there are no negative-weight cycles and d [u] is the weight σ change propagation approaches (e.g., [4, 34]), in DC all ob- of a simple path in G ⊎ G, then so is d [v] = old fcuv (σ) jects allocated statically or dynamically are non-reactive by d [u]+ w (u, v). Furthermore, as c never increases dis- σ σ uv default. Reactive locations are allocated dynamically using tances, then d [v] ≤ d [v] . Therefore, σ f uv (σ). fcuv (σ) σ c library functions rmalloc and rfree, which work just like This shows that f uv is inflationary. ✷ c malloc and free, but on a separate heap. It is not difficult to see that, if all distances are correct before Opening and Closing Atomic Blocks. Atomic blocks are an update, then the solver is started on a store σ ∈ Σ . As sp supported in DC using two library functions and all the hypotheses of Theorem 1 hold, the solver converges begin at ′ end at. Calling begin at opens an atomic block, which to store σ ∈ Σ that is a common fixpoint of all f uv . sp c should be closed with a matching call to end at. Nested Therefore: (1) d ′ [u]’s are weights of simple paths in G, σ atomic blocks are allowed, and are handled using a counter and (2) they satisfy all Bellman’s inequalities. It is well of nesting levels so that the solver is only resumed at the end known [5] that node labels satisfying both properties (1) and of the outer block, processing any pending constraints that (2) are in fact the correct distances in the graph. need to be first executed or brought up to date as a result of Running Time. If we let function pick(S) return the con- the block’s execution. straint cuv ∈ S with the largest variation of d[u] due to the 1 update, then we can adapt results from [18] and show that A detailed documentation of the DC application programming in- terface, including stricter library naming conventions and several ad- each cuv is executed by the solver at most once per update. ditional features not covered in this paper, is available at the URL: If pick uses a standard priority queue with O(log n) time http://www.dis.uniroma1.it/~ demetres/dc/
9 2018/10/22 Creating and Deleting Constraints. For the sake of sim- struct robject { plicity, in Section 2 constraints have been modeled as ordi- void* operator new(size_t size) { return rmalloc(size); } void operator delete(void* ptr) { rfree(ptr); } nary commands. DC takes a more flexible approach: con- }; straints are specified as closures formed by a function that static void con_h(void*), fin_h(void*); carries out the computation and a user-defined parame- class rcons { ter to be passed to the function. Different constraints may int id; public: therefore share the same function code, but have differ- virtual void cons() = 0; ent user-defined parameters. New constraint instances can virtual void final() {} rcons() { id = -1; } be created by calling newcons, which takes as parameters ~rcons() { disable(); } a pointer cons to a function and a user-defined parame- void enable() { if (id == -1) id = newcons(con_h, this); } void disable() { if (id != -1) { delcons(id); id = -1; } } ter param. When invoked in non-atomic normal execution void arm_final() { if (id != -1) arm_final(id, fin_h); } mode, newcons executes immediately function cons with void unarm_final() { if (id != -1) arm_final(id, NULL); } }; parameter param, and logs all dependencies between the created constraint and the reactive locations read during the void con_h(void* p) { ((rcons*)p)->cons(); } void fin_h(void* p) { ((rcons*)p)->final(); } execution. If a constraint is created inside an atomic block (or inside another constraint), its first evaluation is deferred Figure 7. C++ wrapping of DC primitives. until the end of the execution of the current block (or con- straint). All subsequent re-executions of the constraint trig- the underlying imperative program interrupted by the solver gered by modifications of the reactive cells it depends on activation. This can be done by calling function arm final will be performed with the same value of param specified at during constraint solving: the operation schedules a final the creation time. newcons returns a unique id for the cre- handler to be executed at the end of the current solving ses- ated constraint, which can be passed to delcons to dispose sion. The function takes as parameters a constraint id and a of it. pointer to a final handler, or NULL to cancel a previous re- Reading and Modifying Objects. Reading and modifying quest. A final handler receives the same parameter as the objects in reactive memory can be done in DC by evaluating constraint it is associated to, but no dependencies from reac- ordinary C/C++ expressions. We remark that no syntax ex- tive locations are logged during its execution. All final han- tensions or explicit macro/function invocations are required. dlers are executed in normal execution mode as a whole in- side an atomic block. Customizing the Scheduler. Differently from other ap- proaches [34], DC allows programmers to customize the C++ Wrapping of DC Primitives. The examples in the re- execution order of scheduled constraints. While the default mainder of this paper are based on a simple C++ wrapping pick function of DC (which gives higher priority to least re- of the DC primitives, shown in Figure 7. We abstract the cently executed constraints) works just fine in practice for a concepts of reactive object and constraint using two classes: large class of problems (see Section 7), the ability to replace robject and rcons. The former is a base class for objects it can play an important role for some specific problems, as stored in reactive memory. This is achieved by overloading we have seen in the incremental shortest paths example of the new and delete operators in terms of the correspond- Section 3.3. DC provides a function set comp that installs ing DC primitives rmalloc and rfree, so that all member a user-defined comparator to determine the relative priority variables of the object are reactive. Class rcons is a virtual of two constraints. The comparatorreceives as argumentsthe base class for objects representing dataflow constraints. The user-defined parameters associated with the constraints to be class provides a pure virtual function called cons, to be de- compared. fined in subclasses, which provides the user code for a con- straint. An additional empty final function can be option- Final Handlers. An additional feature of DC, built on top ally overridden in subclasses to define the finalization code of the core constraint handling mechanisms described in for a constraint. The class also provides functions enable Section 4, is the ability to perform some finalization oper- and disable to activate/deactivate the constraint associated ations only when the results of constraint evaluations are with the object, and functions arm final and unarm final stable, i.e., when the solver has found a common fixpoint. to schedule/unschedule the execution of final handlers. For instance, a constraint computing the attribute of a wid- get in a graphic user interface may also update the screen by calling drawing primitives of the GUI toolkit: if a redrawing 5. Applications and Programming Examples occurs at each constraint execution, this may cause unnec- In this section, we discuss how DC can improve C/C++ essary screen updates and flickering effects. Another usage programmability in three relevant application scenarios. To example of this feature will be given in Section 5.3. the best of our knowledge, these applications have not been DC allows users to specify portions of code for a con- explored before in the context of dataflow programming. All straint to be executed as final actions just before resuming the code we show is real.
10 2018/10/22 template
11 2018/10/22 constraint
constraint node: robject, rcons val 22 val 16 op + op + root cons depends root left right on reactive cell left right tree update operation: cons writes root->right->right->val = 3; reactive cell constraint val 10 constraint val 12 constraint val 10 constraint val 6 op n/a op * op n/a op * left right left right left right left right NULL NULL NULL NULL
val 2 constraint val 6 constraint val 2 constraint val 3 constraint op n/a op n/a op n/a op n/a left right left right left right left right NULL NULL NULL NULL NULL NULL NULL NULL
Figure 9. Reactive expression tree (left) and change propagation chain after a leaf value update (right). of the problem at hand, which in some cases can be crucial tern [14] answers the above concerns by defining one-to- for coding algorithms provably faster than recomputing from many dependencies between objects so that when one ob- scratch. ject (the subject) changes state, all its dependents (the ob- Traceable data types [4] have been recently introduced to servers) are automatically notified. A key aspect is that sub- extend the class of static algorithms that can be handled ef- jects send out notifications of their change of state, without ficiently by self-adjusting computation: in a traceable data having to know who their observers are, while any number type, dependencies are tracked at the level of data structure of observers can be subscribed to receive these notifications operations, rather than individual memory locations, com- (subjects and observers are therefore not tightly coupled).A bining in a hybrid approach the benefits of automatic change widely deployed embodiment of this pattern is provided by propagation and those of ad hoc dynamic data structures. the Qt application development framework [22]. This can yield large asymptotic gains in dynamizing static Qt is based on a signal-slot communication mechanism: algorithms that use basic abstract data types, such as dictio- a signal is emitted when a particular event occurs, whereas a naries or priority queues. However, it is not clear that every slot is a function that is called in response to a particular sig- conventional static algorithm can be effectively dynamized nal. An object acting as a subject emits signals in response in this way: for some complex problems, it may be neces- to changes of its state by explicitly calling a special mem- sary to implement an ad hoc traceable data structure that per- ber function designated as a signal. Observers and subjects forms all the incremental updates, thus missing the advan- can be explicitly connected so that any signal emitted by a tages of automatic change propagation and thwarting the au- subject triggers the invocation of one or more observer slots. tomatic incrementalization nature of self-adjusting computa- Programmers can connect as many signals as they want to a tion. In contrast, dataflow constraints can explicitly deal with single slot, and a signal can be connected to as many slots changesto the state of the program(when this is necessary to as they need. Since the connection is set up externally af- obtain asymptotic benefits), incorporating change-awareness ter creating the objects, this approach allows objects to be directly within the code controlled by the change propaga- unaware of the existence of each other, enhancing informa- tion algorithm without requiring traceable data structures. tion encapsulation and reuse of software components. Sub- jects and observers can be created in Qt as instances of the 5.2 Implementing the Observer Design Pattern QObject base class. Qt’s signal-slot infrastructure hinges upon an extension of the C++ language with three new key- As a second example, we show how the reactive nature of words: signal and slot, to designate functions as signals our framework can be naturally exploited to implement the or slots, and emit, to generate signals. observer software design pattern. A common issue arising from partitioning a system into a collection of cooperating A Minimal Example: Qt vs. DC. To illustrate the concepts software modules is the need to maintain consistency be- discussed above and compare Qt and DC as tools for imple- tween related objects. In general, a tight coupling of the menting the observer pattern, we consider a minimal exam- involved software components is not desirable, as it would ple excerpted from the Qt 4.6 reference documentation. The reduce their reusability. For example, graphical user inter- goal is to set up a program in which two counter variables a face toolkits almost invariably separate presentational as- and b are connected together so that the value of b is auto- pects from the underlying application data management, al- matically kept consistent with the value of a. The example lowing data processing and data presentation modules to starts with the simple declaration shown in Figure 10(a) (all be reused independently. The observer software design pat- except the framed box), which encapsulates the counter into
12 2018/10/22 an object with member functions value/setValue for ac- class Counter : public robject { cessing/modifying it. Figure 10(b) shows how the Counter public: class can be modified in Qt so that counter modifications Counter() { m_value = 0; } can be automatically propagated to other objects as pre- int value() const { return m_value; } scribed by the observer pattern. First of all, the class inherits void setValue(int value) { m_value = value; } private: from Qt’s QObject base class and starts with the Q OBJECT int m_value; macro. Function setValue is declared as a slot and it is }; augmented by calling explicitly the valueChanged signal (a) A counter class and its DC observer pattern version (framed box). with the emit keyword every time an actual change occurs. class Counter : public QObject { Since Qt Counter objects contain both signal and slot func- Q_OBJECT tions they can act both as subjects and as observers. The fol- public: Counter() { m_value = 0; } lowing code snippet shows how two counters can be created int value() const { return m_value; } and connected so that each change to the former triggers a public slots: change of the latter: void setValue(int value); signals: Counter *a = new Counter, *b = new Counter; void valueChanged(int newValue); private: QObject::connect(a, SIGNAL(valueChanged(int)), int m_value; b, SLOT(setValue(int))); }; a->setValue(12); // a->value() == 12, b->value() == 12 void Counter::setValue(int value) { b->setValue(48); // a->value() == 12, b->value() == 48 if (value != m_value) { m_value = value; The QObject::connect call installs a connection between emit valueChanged(value); counters a and b: every time emit valueChanged(value) } } is issued by a with a given actual parameter, setValue(int (b) Qt observer pattern version of the counter class. value) is automatically invoked on b with the same param- Figure 10. Observer pattern example excerpted from the Qt eter. Therefore, the call a->setValue(12) has as a side- 4.6 reference documentation: DC vs. Qt implementation. effect that the value of b is also set to 12. Conversely, the call b->setValue(48) entails no change of a as no con- nection exists from b to a. of subject and observer classes with extra machinery (see The same result can be achieved in DC by just letting Figure 10); the Counter class of Figure 10(a) inherit from the robject • only actual changes of an object’s state trigger propaga- base class ofFigure7. As a result,the m value member vari- tion events, so programmers do not have to make explicit able is stored in reactive memory. The prescribed connection checks such as in Counter::setValue’s definition to between reactive counters can be enforced with a one-way prevent infinite looping in the case of cyclic connections dataflow constraint that simply assigns the value of b equal (see Figure 10(b)); to the value of a: • DC does not require extensions of the language, and thus Counter *a = new Counter, *b = new Counter; the code does not have to be preprocessed before being compiled. struct C : rcons { Counter *a, *b; We sketch below further points that make dataflow con- C(Counter *a, Counter *b) : a(a), b(b) { enable(); } void cons() { b->setValue(a->value()); } straints a flexible framework for supporting some aspects } c(a,b); of component programming, putting it into the perspective of mainstream embodiments of the observer pattern such as a->setValue(12); // a->value() == 12, b->value() == 12 Qt: b->setValue(48); // a->value() == 12, b->value() == 48 • We notice that the role of the QObject::connect of the in DC, only subjects need to be reactive, while observers Qt implementation is now played by a dataflow constraint, can be of any C++ class, even of third-party libraries dis- yielding exactly the same program behavior. tributed in binary code form. In Qt, third-party observers must be wrapped using classes equipped with slots that Discussion. The example above shows that DC’s run- act as stubs; time system handles automatically a number of aspects that • relations between Qt objects are specified by creating ex- would have to be set up explicitly by the programmers using plicitly one-to-one signal-slot connections one at a time; ’s mechanism: Qt a single DC constraint can enforce simultaneously any • there is no need to define slots and signals, relieving arbitrary set of many-to-many relations. Furthermore, programmers from the burden of extending the definition as the input variables of a dataflow constraint are de-
13 2018/10/22 0 template
14 2018/10/22
fixed 2 fixed
offset ,
t t 30 e so er. out tive t tion info
BSS Text
Data Heap
Stack
mmaps
Shadow memory memory memory Reactive Reactive
2018/10/22
Reactive space kernel
32 + 31 31 30 0 2 , which is 2 2 2 brk t is instrumented with ad- derived from x ′ first tries to access a reac- , t ′ t x region of the address space so is smaller than 5 f that contain the actual protected with a jump to a new version f by overwriting its initial 5 bytes with a jump to x shadow pages system call. Any access to a reactive ends with a jump that leads back to the end of may contain several memory access instructions, it where traces are padded with trailing ′ ′ t t f instructions so that the smallest trace is at mmap of is raised. In the SIGSEGV handler, we patch the trace ′
is re-generated every timereactive a memory new is instructioncode, discovered. we that analyze To accesses statically the identify binary code traces when it in is loaded the that control flow can continueSince normally in the original code. nop least 5-bytes long. Shadow Memory andTo avoid Address expensive Redirecting. un-protectpage operationsat and each re-protect access to reactiveory, mem- we mirror reactive memory pagesprotected with un- data. The shadow memoryder the region control is of kept ourtor, un- reactive which memory maps alloca- itthe onto physical framesobject with is transparently redirectedsponding to object the in corre- theresult, shadow memory memory. locations Asthe a at reactive addresses memory region within read are or never written actually by theing program. memory To avoid without wast- actuallyactive memory accessing can it, be placed re- withinspace, the located Kernel in the upperspace 1GB on of 32-bit the Linux address machinessical 3/1 with virtual the address clas- split.page Kernel tables space as is exclusive to flagged privilegedthus in code th an (ring 2 AV or is lower) touch triggered it. More if recent a 64-bit platforms user-mode offer instruction even more tries flexi- to bytes and thus cannot be patched,the we beginning of overwrite f and we construct aaddress lookup table of that each maps memorythe the access trace instruction to containingwhere a it. trace To in a handle function the cases ditional inline code that accesses reactive locations with generating AVs, and possibly activates the constraint solv Trace x tive location, a segmentation fault with offending instruc a dynamically recompiled trace containing that any read/write access toSince access a violation reactive handling object is raisesjust very an to inefficient, AV. detect we incrementally use i instructionsmemory. that When access an reac instruction placed in a code cache. In trace tection hardware. Our key(AV) technique combined uses access with violations basic dynamic mechanism binary to code tracememory patching locations. read/write operations as to a reactive Access Violations and Dynamic Code Patching. memory is kept in a
process address space address process x
node: robject snode: rcons d s- 15 cache memory p- ng
and code shadow S C D W prev 1 , which NULL 4 NULL next m refc head tail val next rmalloc prev 1 11 next m refc constraint solver scheduler head tail constraint val constraintsolver next prev 1 reactivememory manager , which defines the 7 checks if the invariant property m m m NULL next m refc constraint factory DC runtimelibrary DC’s software architecture. head tail val binary code patcher next rep memory access logger binary image analyzer is satisfied for all nodes in the list, and reactive memory allocator reactive 0
dispatcher watched list A reactive doubly-linked list, monitored by a list next m refc head tail Figure 13. / NULL . primitives and provides support for tracing accesses
trampoline insert. mem. reactive read/ write
SIGSEGV
cons ELF patched code patched delcons newcons rfree m m gen map rmalloc/
watcher map lookup code application watcher Figure 12. // manipulate the... list The repairer object 6.1 Reactive Memory Taking inspiration from transactional memoriesplemented [1], reactive memory we using im- off-the-shelf memory pro- ing track of dependenciestions and between constraints. reactive We start memoryhow our description loca- to by support discussi reactivethe memory, whole which architecture. is the backbone of schedules and dispatches the execution of constraints, kee to reactive memory locations; 2) a rfree 6. Implementation In this section we discussa how combination DC of runtime can libraries, be hardware/operating implemented sy via during the execution of thedifferent program. watchers may We notice be created that to several monitor the same list. tem support, and dynamic codeany patching, source without code requiring preprocessing.our The DC overall implementation, architecture which of IA-32 platform, was is developed shown on inthe a Figure 13. DC Linux At runtime a library veryreactive high is memory level, stratified manager into two modules: 1) a recovers it to a consistent state if any violation is detecte == x->next->prev bility to accomodate reactive memory in protected regions A critical aspect is how to clean up old dependencies in of the address space. We let the reactive memory region D when a constraint is re-evaluated. To solve the problem start at address 230 +231 = 0xC000000 and grow upward efficiently in constant amortized time per list operation, we as more space is needed (see the figure on the right). The keep for each node its insertion time into the linked list. shadow memory region starts at address 231 = 0x8000000 We say that a node is stale if its timestamp is older than and grows upward, eventually hitting the memory mapping the timestamp of the constraint it refers to, and up to date segment used by Linux to keep dynamic libraries, anony- otherwise. Our solver uses a lazy approach and disposes of mous mappings, etc. Any reactive object at address x is mir- stale nodes only when the word they refer to is modified and rored by a shadow object at address x − δ, where δ =230 = the linked list is traversed to add constraints to S. To prevent 0x4000000 is a fixed offset. This makes address redirecting the number of stale nodes from growing too large, we use an very efficient. incremental garbage collection technique. 6.2 Constraint Solver 7. Experimental Evaluation Our implementation aggregates reactive locations in 4-byte In this section we present an experimental analysis of the words aligned at 32 bit boundaries. The solver is activated performances of DC in a variety of different settings, show- every time such a word is read in constraint execution mode, ing that our implementation is effective in practice. or its value is modified by a write operation. The main involved units are (see Figure 13): 7.1 Benchmark Suite We have evaluated DC on a set of benchmarks that includes 1. A dispatcher that executes constraints, maintaining a a variety of problems on lists, grids, trees, matrices, and global timestamp that grows by one at each constraint graphs, as well as full and event-intensive interactive appli- execution. For each constraint, we keep the timestamp of cations. its latest execution. • Linked Lists. We considered several fundamental prim- 2. A memory access logger that maintains the set of depen- itives on linear linked data structures, which provide a dencies D and a list W of all reactive memory words variety of data manipulation patterns. Our benchmarks written by the execution of the current constraint cself , along with their initial values before the execution. To include data structures for: computing the sum of the ele- avoid logging information about the same word multi- ments in a list (adder),filtering the items of a list accord- ing to a given function ( ), randomly assigning ple times during the execution of a constraint, the logger filter stamps each word with the time of the latest constraint each element of a list to one of two output lists (halver), mapping the items of a list onto new values according to execution that accessed it. Information is logged only if a given mapping function ( ), merging two sorted the accessed word has a timestamp older than the current mapper global timestamp, which can only happen once for any lists into a single sorted output list (merger), produc- ing a sorted version of an input list (msorter), produc- constraint execution. To represent D, the logger keeps for ing a reversed version of an input list (reverser); split- each word v the address of the head node of a linked list ting a list into two output lists, each containing only ele- containing the id’s of constraints depending upon v. ments smaller or, respectively, greater than a given pivot 3. A constraint scheduler that maintains the set of sched- (splitter). All benchmarks are subject to operations uled constraints S. By default S is a priority queue, where that add or remove nodes from the input lists. the priority of a constraint is given by the timestamp of • Graphs and Trees. Benchmarks in this class include clas- its latest execution: the scheduler repeatedly picks and lets the dispatcher execute the constraint with the highest sical algorithmic problems for routing in networks and tree computations: priority, until S gets empty. Upon completion of a con- straint’s execution, words are scanned and removed from sp: given a weighted directed graph and a source node W : for each v ∈ W whose value has changed since the s, computes the distances of all graph nodes from s. beginning of the execution, the constraint id’s in the list Graph edges are subject to edge weight decreases (see of nodes associated with v are added to S, if not already Section 3.3). there. exptrees: computes the value of an expression tree Nodes of the linked lists that represent D and data struc- subject to operations that change leaf values or opera- tures S and W are kept in contiguous chunks allocated with tors computed by internal nodes (see Section 5.1). malloc. To support direct lookup, timestamps and depen- • Linear Algebra. We considered number-crunching prob- dency list heads for reactive memory words are stored in a lems on vectors and matrices, including the product of a contiguous reactive memory info region that starts at address vector and a matrix (vecmat) and matrix multiplication 231 = 0x8000000 and grows downward, eventually hitting (matmat), subject to different kinds of updates of single the heap’s brk. cells as well as of entire rows or columns.
16 2018/10/22 From-scratch time Propagation time Mem peak usage DC statistics (secs) (msecs) (Mbytes) dc ceal ceal ceal ceal avg cons instr patched Benchmark conv dc ceal conv conv dc dc ceal dc dc ceal dc per update time instr adder 0.10 1.44 1.40 14.40 14.00 0.97 0.68 85.80 126.17 211.54 232.87 1.10 1.5 0.030 26 exptrees 0.14 1.02 1.07 7.28 7.64 1.04 4.11 5.46 1.32 143.30 225.32 1.57 15.6 0.028 72 filter 0.19 2.08 1.11 10.94 5.84 0.53 0.63 2.49 3.95 265.78 189.47 0.71 0.5 0.032 39 halver 0.20 2.08 1.33 10.40 6.65 0.63 0.61 3.95 6.47 269.10 218.22 0.81 0.5 0.030 38 mapper 0.19 2.04 1.30 10.73 6.84 0.63 0.61 2.63 4.31 261.53 214.34 0.81 0.5 0.032 39 merger 0.19 2.12 1.37 11.15 7.21 0.64 0.66 4.43 6.71 284.41 218.21 0.81 0.5 0.031 57 msorter 0.91 5.18 3.91 5.69 4.29 0.75 5.55 15.91 2.86 689.59 820.14 1.18 37.6 0.031 75 reverser 0.18 2.04 1.30 11.33 7.22 0.63 0.62 2.63 4.24 267.45 214.34 0.80 0.5 0.030 37 splitter 0.18 2.27 1.31 12.61 7.27 0.57 1.54 3.92 2.54 344.60 222.34 0.64 1.5 0.031 56
Table 1. Performance evaluation of DC versus CEAL, for a common set of benchmarks. Input size is n =1, 000, 000 for all tests except msorter, for which n = 100, 000.
Update times - Mapper benchmark Total update times - Adder benchmark Performance ratio CEAL/DC - Adder benchmark 1000 180 90 DC CEAL CEAL/DC 100 CEAL 160 DC 80 conv 140 70 10 120 60 1 100 50
0.1 80 Ratio 40
Seconds 60 30 Milliseconds 0.01 40 20 0.001 20 10 0.0001 0 0 0.0001 0.001 0.01 0.1 1 10 100 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Percentage of input changed Number of nodes x 100000 Number of nodes x 100000 (a) (b) (c) Figure 14. (a) Change propagation times on the mapper benchmark for complex updates with input size n = 100, 000; (b-c) performance comparison of the change propagation times of DC and CEAL on the adder benchmark.
• Interactive Applications. We considered both full real ap- slot mechanism provided by Qt (conventional versions). To plications and synthetic worst-case scenarios, including: assess the performances of DC against competitors that othello: full application that implements the well- can quickly respond to input changes, we have also con- known board game in which two players in turn place sidered highly tuned ad-hoc dynamic algorithms [18, 36] colored pieces on a square board, with the goal of re- and incremental solutions realized in CEAL [25], a state- versing as many of their opponent’s pieces as possi- of-the-art C-based language for self-adjusting computation. ble; Benchmarks in common with CEAL are adder, exptrees, filter, halver, mapper, merger, msorter, reverser, buttongrid: event-intensive graphic user interface and splitter. For these benchmarks, we have used the application with a window containing n × n push optimized implementations provided by Hammer et al. [25]. buttons embedded in a grid layout. This is an extreme artificial scenario in which many events are generated, 7.2 Performance Metrics and Experimental Setup since a quadratic number of buttons need to be resized We tested our benchmarks both on synthetic and on real test and repositioned to maintain the prescribed layout at sets, considering a variety of performance metrics: each interactive resize event. • Running times: we measured the time required to initial- Some benchmarks, such as matmat and sp, are very com- ize the data structures with the input data (from-scratch putationally demanding. For all these benchmarks we have execution), the time required by change propagation, and considered an implementation based on DC, obtained by binary code instrumentation time. All reported times are making the base data structures (e.g., the input list) reac- wall-clock times, averaged over three independent trials. tive, and a conventional implementation in C based on non- Times were measured with gettimeofday(), turning reactive data structures. Interactive applications (othello off any other processes running in the background. and buttongrid)are written in the Qt-4 framework: change • Memory usage: we computed the memory peak usage as propagation throughout the GUI is implemented either us- well as a detailed breakdownto assess which components ing constraints (DC versions), or using the standard signal- of our implementation take up most memory (constraints,
17 2018/10/22 Incremental routing - comparison msorter, for which n = 100, 000), where n is the length 1000 of the input list for the list-based benchmarks, and the num- rr sp (custom pick) ber of nodes in the (balanced) input tree for exptrees. Ta- sp (default pick) sq ble 1 reports from-scratch execution times of both DC and 100 CEAL (compared to the corresponding conventional imple- mentations), average propagation times in response to small 10 changes of the input, memory usage and some DC stats (av- erage number of executed constraints per update, executable 1 instrumentation time, and total number of patched instruc- tions). The experiments show that our DC implementation
0.1 performs remarkably well. From-scratch times are on aver- Average time per update (msec) age a factor of 1.4 higher than those of CEAL, while prop- agation times are smaller by a factor of 4 on average for 0.01 NY BAY COL FLA NW NE all tests considered except the adder, yielding large speed- Road network ups over complete recalculation. In the case of the adder benchmark, DC leads by a huge margin in terms of propa- Figure 15. Analysis of different pick function definitions gation time (see Figure 14a and Figure 14b), which can be on the incremental routing problem. attributed to the different asymptotic performance of the al- gorithms handling the change propagation (constant for DC, shadow memory, reactive memory, stale and non-stale and logarithmic in the input size for the list reduction ap- dependencies, etc.). proach used by CEAL). We remark that the logarithmic bound of self-adjusting computation could be reduced to • DC-related statistics: we collected detailed profiling in- constant by using a traceable accumulator, as observed in formation including counts of patched instructions, stale Section 5.1 (however, support for traceable data structures is dependencies cleanups, allocated/deallocated reactive not yet integrated in CEAL). blocks, created/deleted constraints, constraints executed We also investigated how DC and CEAL scale in the case per update, and distinct constraints executed per update. of batches of updates that change multiple input items si- All DC programs considered in this section, except for sp multaneously. The results are reported in Figure 14a for the that will be discussed separetely, use the default timestamp- representative mapper benchmark, showing that the selec- based comparator for constraint scheduling. tive recalculations performed by DC and CEAL are faster than recomputing from scratch for changes up to significant Experimental Platform. The experiments were performed percentages of the input. on a PC equipped with a 2.10 GHz Intel Core 2 Duo with 3 GB of RAM, running Linux Mandriva 2010.1 with Qt 4.6. All programs were compiled with gcc 4.4.3 and optimiza- Comparison to ad hoc Incremental Shortest Paths. We tion flag -O3. now consider an application of the shortest path algorithm 7.3 Incremental Computation discussed in Section 3.3 to incremental routing in road net- works. We assess the empirical performance of a constraint- As observed in Section 3.3, the reactive nature of our mixed based solution implemented in DC (sp) by comparing it imperative/dataflow framework makes it a natural ground with Goldberg’s smart queue implementation of Dijkstra’s for incremental computation. In this section, we present ex- algorithm (sq), a highly-optimized C++ code used as the perimental evidence that a constraint-based solution in our reference benchmark in the 9th DIMACS Implementation framework can respond to input updates very efficiently. We Challenge [20], and with an engineered version of the ad hoc first show that the propagation times are comparable to state incremental algorithm by Ramalingam and Reps (rr) [18, of the art automatic change propagation frameworks, such as 36]. Our code supports update operations followingthe high- CEAL [25], and for some problems can be orders of magni- level description given in Figure 5, except that we create one tude faster than recomputing from scratch. We then consider constraint per node, rather than one constraint per edge. We a routing problem on real road networks, and compare our used as input data a suite of US road networks of size up to DC-based solution both to a conventional implementation 1.5 million nodes and 3.8 million edges derived from the UA and to a highly optimized ad hoc dynamic algorithm sup- Census 2000 TIGER/Line Files [37]. Edge weights are large porting specific update operations. and represent integer positive travel times. We performed on Comparison to CEAL. Table 1 summarizes the outcomes each graph a sequence of m/10 random edge weight de- of our experimental comparison with the conventional ver- creases, obtained by picking edges uniformly at random and sion and with CEAL for all common benchmarks. Input reducing their weights by a factor of 2. Updates that did not size is n = 1, 000, 000 for all tests (with the exception of change any distances were not counted.
18 2018/10/22 Road network From-scratch Propagation Speedup Mem peak usage Statistics time (msec) time (msec) (Mbytes) 3 3 sq sq sp cons rr node scans Graph n · 10 m · 10 sq sp rr sp rr sp rr sq per update per update NY 264 733 50.99 0.16 0.07 318.6 728.4 76.75 26.62 26.19 143.9 143.9 BAY 321 800 59.99 0.15 0.07 399.9 857.0 84.84 30.21 29.82 170.6 170.5 COL 435 1, 057 79.98 0.28 0.17 285.6 470.4 108.61 39.09 38.97 378.3 378.2 FLA 1, 070 2, 712 192.97 0.63 0.35 306.3 551.3 251.26 93.42 93.29 687.5 687.3 NW 1, 207 2, 840 236.96 0.87 0.54 272.3 438.8 270.66 102.15 101.53 1002.4 1002.3 NE 1, 524 3, 897 354.94 0.27 0.16 1314.5 2218.3 350.86 132.85 132.15 320.2 320.1
Table 2. Performance evaluation of DC for incremental routing in US road networks using up to 1.5 million constraints.
Total and change propagation times per resize event Total and change propagation times per move 120 3 buttongrid-DC (total) buttongrid-Qt (total) 100 buttongrid-DC (change prop.) 2.5 buttongrid-Qt (change prop.)
80 2 othello-DC (total) (a) 60 (b) 1.5 othello-Qt (total) othello-DC (change prop.) othello-Qt (change prop.) 40 1
20 Average time per move (msec) 0.5 Average time per resize (msec)
0 0 8x8 12x12 16x16 20x20 24x24 8x8 12x12 16x16 20x20 Grid size (n x n) Board size (n x n)
Figure 16. Comparison with signal-slot mechanism in Qt: (a) buttongrid; (b) othello.
The results of our experiments are shown in Table 2 and intensive interactive applications by comparing the DC im- Figure 15. Both sp and rr were initialized with distances plementations of buttongrid and othello with the con- computed using sq, hence we report from-scratch time only ventional versions built atop Qt’s signal-slot mechanism. for this algorithm. Due to the nature of the problem, the In buttongrid, each constraint computes the size and average number of node distances affected by an update is position of a button in terms of the size and position of rather small and almost independent of the size of the graph. adjacent buttons. We considered user interaction sessions Analogously to the incremental algorithm of Ramalingam with continuous resizing, which induce intensive schedul- and Reps, the automatic change propagation strategy used ing activity along several propagation chains in the acyclic by our solver takes full advantage of this strong locality, re- dataflow graph. In othello, constraints are attached to cells evaluating only affected constraints and delivering substan- of the game board (stored in reactive memory) and main- tial speedups over static solutions in typical scenarios. Our tain a mapping between the board and its graphical repre- DC-based implementation yields propagation times that are, sentation: in this way, the game logic can be completely un- on average, a factor of 1.85 higher than the conventional ad aware of the GUI backend, as prescribed by the observer hoc incremental algorithm, but it is less complex, requires pattern (see Section 5.2). For both benchmarks, we experi- fewer lines of code, is fully composable, and is able to re- mented with different grid/board sizes. Figure 16 plots the spond seamlessly to multiple data changes, relieving the pro- average time per resize event (buttongrid) and per game grammer from the task of implementing explicitly change move (othello), measured over 3 independent runs. Both propagation. We also tested sp with different types of sched- the total time and the change propagation time are reported. ulers. By customizing the pick function of the default prior- For all values of n, the performance differences of the DC ity queue scheduler (giving highest priority to nodes closest and Qt conventional implementations are negligible and the to the source), a noticeable performance improvement has curves are almost overlapped. Furthermore, the time spent been achieved (see Figure 15). We also tried a simple stack in change propagation is only a small fraction of the total scheduler, which, however, incurred a slowdown of a factor time, showing that the overhead introduced by access viola- of 4 over the default scheduler. tions handling, instrumentation, and scheduling in DC can be largely amortized over the general cost of widget man- 7.4 Comparison to Qt’s Signal-slot Mechanism agement and event propagation in Qt and in its underlying Maintaining relations between widgets in a graphic user in- layers. terface is one of the most classical applications of dataflow constraints [38]. We assess the performance of DC in event-
19 2018/10/22 Vector-matrix product: memory usage as a function of block size Vector-matrix product: time as a function of the block size (log-log scale) 300 1024 constraints (dc) Single cell update constraints (user) Batch of column cell updates 250 shadow memory (dc) reactive memory (user) 256 dependencies more dc internals 200 code + stack at startup 64
150 (a) (b) 16
100 4
50
Memory usage breakdown (MB) 2000 1 Avg update time per changed cell (us) 1000 125 63 32 16 8 2 1 500 250 4 0 1 2 4 8 16 32 64 128 256 512 10242000 1 2 4 8 16 32 64 128 256 512 1024 2048 Block size b Block size b Figure 17. Analysis of vecmat as a function of the block size: (a) memory usage; (b) update time for two different kinds of updates. Point labels indicate the number of constraints executed in each batch (for single cells updates, the number of executed constraints is always 1, but a constraint does more work as b increases).
If the block size is n, then there is a constraint per matrix Time required for dynamic code instrumentation 1.4 column: constraint cj associated with column j computes 1.2 the scalar product between V and M[·][j] and updates the 1 j-th entry of the output vector with the new value. The ap- 0.8 proach can be naturally adapted to deal with any block size 0.6 b ∈ [1,n]. Seconds 0.4 In Figure 17 we reportthe outcome of an experimentwith 0.2 n = 2000 in which we increased the block size b from1 to n. 0 As shown in Figure 17a, the memory usage is inversely pro- 0 0.5 1 1.5 2 2.5 portional to b, and thus directly proportional to the number Executable size (Megabytes) of constraints: the memory used for maintaining constraints is about half of the total amount when b =1, and negligible Figure 18. Time required for dynamic instrumentation. when b = n. All the other components (in particular, reactive memory, shadow memory, and dependencies) do not depend 7.5 Fine-grained vs. Coarse-grained Decompositions on the specific block size and remain constant. Figure 17b shows the effect of b on the change propagation times for A relevant feature of DC is that designers can flexibly de- two different kinds of updates. For single cells updates, the cide at which level of granularity a given algorithmic solu- time scales linearly with b (axes are on a log-log scale): this tion can be decomposed into smaller parts, i.e., they might confirms the intuition that if an update changes only a sin- use a single constraint that performs the entire computation gle cell, implementations using larger block sizes perform a (coarse-grained decomposition), or many constraints each lot of unnecessary work. The scenario is completely differ- computing only a small portion of the program’s state (fine- ent if single updates need to change entire columns (which is grained decomposition). In reactive scenarios, where con- a typical operation for instance in incremental graph reacha- straints are re-evaluated selectively only on the affected por- bility algorithms [18]): in this case, change propagation time tions of the input, this design choice can have implications not only is not penalized by larger block sizes, but it is also both on memoryusage and on runningtime. To explorethese slightly improved. This is due to the fact that larger values tradeoffs, we experimented with matrix benchmarks matmat of b yield a smaller number of constraints, which induces and vecmat.For brevity,in this section we focus on vecmat, smaller scheduling activity. The improvement, however, is the results for matmat being similar. modest, suggesting that DC’s constraint scheduling over- Let V be a vector of size n and let M be a reactive matrix head is modest compared to the overall work required to of size n×n. Our implementation of the vector-matrix prod- solve a given problem even at the finest-grained decompo- uct algorithm is blocked: constraints are associated to blocks sition where there is one constraint per matrix cell. of matrix cells, where a block is a set of consecutive cells on the same column. If the block size is 1, then there is one 7.6 Instrumentation Overhead constraint per matrix cell: constraint ci,j is responsible of updating the j-th entry of the output vector with the product As a final set of experiments, we have measured how in- V [i]∗M[i][j].Thiscan be donein O(1) time by maintaining strumentation time scales as a function of the executable a local copy of the old product value and updating the result file size. We noticed that the performance overheads are with the difference between the new value and the old one. dominated by the initial static binary code analysis phase
20 2018/10/22 performed during DC’s initialization, which scans the code between the state of a C program an a graphical represen- to index memory access instructions as described in Sec- tation of its data structures [16]. Recently, Meyerovich et tion 6.1. The times required for access violation handling al. [32] have introduced Flapjax, a reactive extension to the and just-in-time binary code patching are negligible com- JavaScript language targeted to Web applications. Flapjax pared to the overall execution times in all tested applications offers behaviors (e.g., variables whose value changes are au- and are not reported. The experiment was conducted by ini- tomatically propagated by the language), and event streams tializing DC on executable files obtained by linking stati- (e.g., potentially infinite streams of discrete events, each of cally object files of increasing total size. The results are re- which triggers additional computations). SugarCubes [12] ported in Figure 18 and indicate that DC scales linearly, with and ReactiveML [31] allow reactive programming (in Java total instrumentation times being reasonably small even for and OCAML, respectively) by relying not on operating sys- large executable sizes. tem and runtime support, as our approach does, but rather on causality analysis and a custom interpreter/compiler. These 8. Related Work systems, however, track dependencies between functional units, through the use of specific language constructs, such The ability of a program to respond to modifications of its as events, and explicit commands for generating and waiting environment is a feature that has been widely explored in a for events. large variety of settings and along rather different research lines. While this section is far from being exhaustive, we Constraint Satisfaction. Dataflow constraints fit within discuss some previous works that appear to be more closely the more general field of constraint programming [7]. Terms related to ours. such as “constraint propagation” and “constraint solving” have often been used in papers related to dataflow since the GUI and Animation Toolkits. Although dataflow pro- early developments of the area [11, 34, 38]. However, the gramming is a general paradigm, dataflow constraints have techniques developed so far in dataflow programming are gained popularity in the 90’s especially in the creation of quite distant from those appearing in the constraint program- interactive user interfaces. Amulet [34] and its predeces- ming literature [9]. In constraint programming, relations be- sor Garnet [33] are graphic user interface toolkits based on tween variables can be stated in the form of multi-way con- the dataflow paradigm. Amulet integrates a constraint solver straints, typically specified over restricted domains such as with a prototype-instance object model implemented on top real numbers, integers, or Booleans. Domain-specific solvers of C++, and is closely related to our work. Each object, use knowledge of the domain in order to forbid explicitly created by making an instance of a prototype object, con- values or combinations of values for some variables [9], sists of a set of properties (e.g., appearance or position) that while dataflow constraint solvers are domain-independent. are stored in reactive variables, called slots. Constraints are Moving from early work on attribute grammars [17, 29], created by assigning formulas to slots. Values of slots are ac- a variety of incremental algorithms for performing effi- cessed through a Get method that, when invoked from inside cient dataflow constraint satisfaction have been proposed of a formula, sets up a dependency between slots. A variety in the literature and integrated in dataflow systems such as of approaches have been tested by the developers to solve Amulet. These algorithms are based either on a mark-sweep constraints [38]. FRAN (Functional Reactive Animation) approach [17, 27], or on a topological ordering [6, 26]. provides a reactive environment for composing multime- In contrast, DC uses a priority-based approach, which al- dia animations through temporal modeling [39]: graphical lows users to customize the constraint scheduling order. objects in FRAN use time-varying, reactive variables to au- Mark-sweep algorithms are preferable when the dataflow tomatically change their properties, achieving an animation graph can change dynamically during constraint evaluation: that is function of both events and time. this may happen if constraints use indirection and condi- Reactive Languages. The dataflow model of computation tionals, and thus cannot be statically analyzed. With both approaches, if there are cyclic dependencies between con- can be also supported directly by programming languages. Most of them are visual languages, often used in industrial straints, they are arbitrarily broken, paying attention to eval- uate each constraint in a cycle at most once. Compared to settings [10], and allow the programmer to directly man- our iterative approach, this limits the expressive power of age the dataflow graph by visually putting links between the various entities. Only a few non-visual languages pro- constraints. vide a dataflow environment, mostly for specific domains. Self-adjusting Computation. A final related area, that we Among them, Signal [24] and Lustre [13] are dedicated to have extensively discussed throughout the paper, is that of programming real-time systems found in embedded soft- self-adjusting computation, in which programs respond to ware, and SystemC [23] is a system-level specification and input changes by updating automatically their output. This is design language based on C++. The data-driven Alpha lan- achieved by recording data and control dependencies during guage provided by the Leonardo software visualization sys- the execution of programs so that a change propagation tem allows programmers to specify declarative mappings algorithm can update the computation as if the program
21 2018/10/22 were run from scratch, but executing only those parts of the [8] R. Bellmann. On a routing problem. Quarterly of Applied computation affected by changes. We refer to [3, 4, 25] for Mathematics, 16:87–90, 1958. recent progress in this field. [9] C. Bessiere. Constraint propagation. In F. Rossi, P. van Beek, and T. Walsh, editors, Handbook of Constraint Programming. 9. Future Work 2006. The work presented in this paper paves the road to several [10] P. A. Blume. The LabVIEW Style Book. Prentice Hall, 2007. further developments. Although conventional platforms of- [11] A. Borning. The Programming Language Aspects of fer limited support for implementing reactive memory effi- ThingLab, a Constraint-Oriented Simulation Laboratory. ciently, we believe that our approachcan greatly benefit from ACM Trans. Program. Lang. Syst., 3(4):353–387, 1981. advances in the hot field of transactional memories, which [12] F. Boussinot and J.-F. Susini. The sugarcubes tool box: a shares with us the same fundamental need for a fine-grained, reactive java framework. Software: Practice and Experience, highly-efficient control over memory accesses. Multi-core 28(14):1531–1550, 1998. platforms suggest another interesting direction. Indeed, ex- [13] P. Caspi, P. Pilaud, N. Halbwachs, and J. Plaice. Lustre, a posing parallelism was one of the motivations for dataflow declarative language for programming synchronous systems. architectures, since the early developments of the area. We In POPL, 1987. regard it as a challenging goal to design effective models and [14] C. Chambers, B. Harrison, and J. Vlissides. A debate on efficient implementations of one-way dataflow constraints in language and tool support for design patterns. In POPL, pages multi-core environments. 277–289, 2000. [15] P. Cousot and R. Cousot. Abstract interpretation: A unified Acknowledgments lattice model for static analysis of programs by construction or We wish to thank Umut Acar and Matthew Hammer for approximation of fixpoints. In POPL, pages 238–252, 1977. many enlightening discussions and for their support with [16] P. Crescenzi, C. Demetrescu, I. Finocchi, and R. Petreschi. CEAL. We are also indebted to Alessandro Macchioni for Reversible execution and visualization of programs with his contributions to the implementation of reactive memory, Leonardo. J. Vis. Lang. Comput., 11(2):125–150, 2000. and to Pietro Cenciarelli and Ivano Salvo for providing use- [17] A. J. Demers, T. W. Reps, and T. Teitelbaum. Incremental ful feedback on the formal aspects of our work. evaluation for attribute grammars with application to syntax- This work was supported in part by the Italian Ministry directed editors. In POPL, pages 105–116, 1981. of Education, University, and Research (MIUR) under PRIN [18] C. Demetrescu. Fully Dynamic Algorithms for Path Problems 2008TFBWL4 national research project “AlgoDEEP: Algo- on Directed Graphs. PhD thesis, Sapienza University of rithmic challenges for data-intensive processing on emerg- Rome, 2001. ing computing platforms”. [19] C. Demetrescu, I. Finocchi, and G. Italiano. Handbook on Data Structures and Applications, chapter 36: Dynamic References Graphs. D. Mehta and S. Sahni (eds.), CRC Press, 2005. [1] M. Abadi, T. Harris, and M. Mehrara. Transactional memory [20] C. Demetrescu, A. V. Goldberg, and D. S. Johnson, editors. with strong atomicity using off-the-shelf memory protection The Shortest Path Problem: Ninth DIMACS Implementation hardware. In PPoPP, pages 185–196, 2009. Challenge. American Mathematical Society, 2009. [2] R. Abraham, M. M. Burnett, and M. Erwig. Spreadsheet [21] B. Demsky and M. Rinard. Automatic detection and repair of programming. In Wiley Encyclopedia of Computer Science errors in data structures. In OOPSLA ’03, pages 78–95, 2003. and Engineering. John Wiley & Sons, Inc., 2008. [22] A. Ezust and P. Ezust. An Introduction to Design Patterns in [3] U. A. Acar, G. E. Blelloch, M. Blume, and K. Tangwongsan. C++ with Qt 4. Prentice Hall, 2006. An experimental analysis of self-adjusting computation. In PLDI, pages 96–107, 2006. [23] T. Groetker, S. Liao, G. Martin, and S. Swan. System Design with SystemC. Kluwer Academic Publishers, 2002. [4] U. A. Acar, G. E. Blelloch, R. Ley-Wild, K. Tangwongsan, and D. T¨urkoglu. Traceable data types for self-adjusting [24] P. L. Guernic, A. Benveniste, P. Bournai, and T. Gautier. computation. In PLDI, pages 483–496, 2010. Signal, a data-flow oriented language for signal processing. IEEE-ASSP, 1986. [5] R. K. Ahuja, T. L. Magnanti, and J. B. Orlin. Network flows: theory, algorithms, and applications. Prentice-Hall, [25] M. Hammer, U. A. Acar, and Y. Chen. CEAL: a C-based Inc., 1993. language for self-adjusting computation. In PLDI, pages 25– 37, 2009. [6] B. Alpern, R. Hoover, B. K. Rosen, P. F. Sweeney, and F. K. Zadeck. Incremental evaluation of computational circuits. In [26] R. Hoover. Incremental graph evaluation. PhD thesis, Dept. ACM-SIAM Symp. on Discrete Algorithms (SODA), pages 32– of Computer Science, Cornell Univ., Ithaca, NY, 1987. 42, 1990. [27] S. E. Hudson. Incremental attribute evaluation: A flexible [7] K.R.Apt. Principles of Constraint Programming. Cambridge algorithm for lazy update. ACM Trans. Prog. Lang. Sys., 13 University Press, 2003. (3):315–341, 1991.
22 2018/10/22 [28] A. Kay. Computer software. Scient. Amer., 251(3):191–207, 1984. [29] D. E. Knuth. Semantics of context-free languages. Theory of Computing Systems, 2(2):127–145, June 1968. [30] M. Z. Malik, K. Ghori, B. Elkarablieh, and S. Khurshid. A case for automated debugging using data structure repair. In ASE, pages 620–624, 2009. [31] L. Mandel and M. Pouzet. ReactiveML, a reactive extension to ML. In Proceedings of 7th ACM SIGPLAN International con- ference on Principles and Practice of Declarative Program- ming (PPDP’05), Lisbon, Portugal, 2005. [32] L. A. Meyerovich, A. Guha, J. Baskin, G. H. Cooper, M. Greenberg, A. Bromfield, and S. Krishnamurthi. Flapjax: a programming language for ajax applications. In OOPSLA, pages 1–20, 2009. [33] B. A. Myers. Garnet: Comprehensive support for graphical, highly-interactive user interfaces. IEEE Computer, 23, 1990. [34] B. A. Myers, R. G. McDaniel, R. C. Miller, A. S. Ferrency, A. Faulring, B. D. Kyle, A. Mickish, A. Klimovitski, and P. Doane. The Amulet environment: New models for effective user interface software development. IEEE Trans. Softw. Eng., 23(6):347–365, 1997. [35] S. Prasad and S. Arun-Kumar. An introduction to operational semantics. In Compiler Design Handbook: Optimizations and Machine Code, pages 841–890. CRC Press, Boca Raton, 2002. [36] G. Ramalingam and T. Reps. An incremental algorithm for a generalization of the shortest-path problem. Journal of Algorithms, 21(2):267 – 305, 1996. [37] U.S. Census Bureau, Washington, DC. UA Census 2000 TIGER/Line Files. http://www.census.gov/geo/www/tiger/, 2002. [38] B. T. Vander Zanden, R. Halterman, B. A. Myers, R. Mc- Daniel, R. Miller, P. Szekely, D. A. Giuse, and D. Kosbie. Lessons learned about one-way, dataflow constraints in the Garnet and Amulet graphical toolkits. ACM Trans. Program. Lang. Syst., 23(6):776–796, 2001. [39] Z. Wan and P. Hudak. Functional reactive programming from first principles. In PLDI, pages 242–252, 2000.
23 2018/10/22