A Graph-Based Semantics Workbench for Concurrent Asynchronous - PowerPoint PPT Presentation

A Graph-Based Semantics Workbench for Concurrent Asynchronous Programs Alexander Heußner Chris Poskitt Otto-Friedrich-Universität ETH Zürich Bamberg Dagstuhl, November 2015

Analysis (Verification) of Evolving Graph Structures 2

CP AH Í verification of dynamic Í assertional reasoning for message passing systems attributed GTS (graph grammars, partial order (see yesterday’s talk) structures, treewidth et al., Í verification of (concurrent) wqos, abstractions) object-oriented programs Í verification of asynchronous Í . . . concurrent systems Í leveraging contracts in Í . . . software correctness Í reasoning for policies with techniques resources via GTS 3

Today’s topic: Formalisations and analysis of di ff erent state-of-the-art concurrency abstractions for concurrent asynchronous (object-oriented) programs. , We are talking about “real” source code here! , 4

Some Initial Problems here: E E models must be highly dynamic (e.g. dynamic generation of threads, channels, queues, stacks, wait/dependency relationships) E expressiveness needed beyond “classical” automaton/Petri net models (e.g. complicated inter process and memory relations) E semi-formal semantics / semantics “by implementation” E di ff erent competing (and contradictory) semantics E changes of semantic meta-model are common (and frequent) 5

Thus: Not one semantic meta model but di ff erent competing and possibly contradictory models that also are rivaled by the mental concurrency model of the programmer. 6

Proposed Solution Í modular/parameterisable semantics (“semantic plug ins”) Í based on graph transformation systems Í formalise dynamic runtime semantics • make scheduler explicit • make queueing model explicit • . . . Í assume static semantics (typing, generics,. . . ) already done 7

FORK; round_ PHILOSOPHER with ID of ‘philosopher ’, forks class Prototypical implementation make ( philosopher: INTEGER; left , right: separate create -- Initialisation make -- Initialise feature > 0 > 0 valid_id: philosopher valid_times_to_eat : round_count Í for SCOOP: an object-oriented message-passing language require Í prototype based on a GTS model in the GROOVE tool philosopher := left id := do left_fork := right Í plugin for o ffi cial Ei ff el Studio IDE (verification version) round_count right_fork := times_to_eat • get “flattened” source code id_set: id = philosopher left_fork_set : left_fork = left • feedback errors to code display right_fork_set : right_fork = right times_to_eat_set : times_to_eat = round_co ensure Í also standalone tool working on SCOOP graphs Í parameterisation by SCOOP’s two most recent end (competing/contradictory) execution models -- Philosopher ’s id. -- Access for th id: INTEGER feature does it remain -- Measurement times times_to_eat : INTEGER many -- How feature (Joint work with Claudio Corrodi.) 8 end

Let’s take a closer look. . . Í example piece of SCOOP(-ish) code separate x,y separate x,y do do x.set_colour(Green) x.set_colour(Indigo) y.set_colour(Green) a_colour = x.get_colour end y.set_colour(a_colour) end Í separate objects are associated with threads of execution that have exclusive responsibility for executing methods on them Í separate block guarantees: calls are queued as requests in program order; and no intervening requests are queued Í consider two di ff erent queueing semantics. . . 9

(blackboard demo) h 0 h 1 h 2,' h 3 h 0 h 3 h 2 h 1 10

Achieved so far. . . X Í formalised the two execution models , straightforward parameterisation by GTS rules and programs Í included “mental models” of engineers behind compilers and existing formal models in interviews , diagrammatic representation and easy simulation Í simple analysis/verification tasks (simulation, deadlock detection,. . . ) help to highlight discrepancies between models , “play” with di ff erent semantic meta-models , highlighted a real inconsistency between the queuing semantics / running time for large programs using the generic verification algorithms 11

A glimpse at the model Í example GTS rule modelling entering a separate block (private queues semantics): refers_to Legend for edge/node colouring: Object handler Memory SubQueue red: negative application cond., @ @ blue: matched and deleted, @ storage green: newly created ReferenceValue @ ∀ next @ @ @ @ value sync next_queue.next* Handler QoQ SubQueue Variable next != n40 active_frame variable storage _private_queue Handler SubQueue _open current_state StackFrame Memory current_state InitialState _creator_frame . Simplified QoQ rule for entering a . . . block, whic 12

Í we use control programs to make the model’s scheduler explicit (open to parameterisation) and to control atomicity initialize_model ; while (progress & no_error) { for each handler p: alap handler_local_execution_step (p)+; try synchronisation_step ; } recipe handler_local_execution_step (p){ try separate_object_creation (p)+; else try assignment_to_variable (p)+; else try ... ; try clean_up_model +; } recipe synchronisation_step (){ reserve_handlers | dequeue_task | ...; } ... // ---------- plug in ---------------------- recipe separate_object_creation (p){ ... } ... 13

Let’s talk about Verification. . . (ongoing work) | Í generic abstractions for SCOOP graphs = Í “well-structuredness” properties of SCOOP graphs Í relation to existing models, submodels, decidable subclasses, . . . Í on-the-fly M2M to counting abstractions (Petri nets) etc. Í general concept of “semantics parameterised verfication” 14

Mid-term/Long-term goals: Í semantic workbench with series of tools usable for the software-engineer (who is writing concurrent software and/or writing compilers/libraries for concurrency abstractions) Í clearer connection to existing approaches (e.g. K etc.) Í structural comparison of concurrency abstractions from a graph perspective Í properly formalise and algorithmically attack “semantics parameterised analysis” 15