DOCSLIB.ORG

An Introduction to Rely/Guarantee Reasoning About Concurrency

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
An Introduction to Rely/Guarantee Reasoning About Concurrency Rely/guarantee An introduction to rely/guarantee reasoning about concurrency Pre I assume that this lecture starts at 8:30am Ian J. Hayes (and Cliff B. Jones) Guarantee you will understand to rely/guarantee reasoning Rely that you ask questions when you don’t understand The University of Queensland, Australia (and Newcastle University, UK) Post finish this lecture at 9:30am SETSS Spring School Chongqing, China 2017-04-17–19 1 / 1 2 / 1 Overview Your background Logic and set theory I Propositional logic: , and ^ _ : I Predicate logic: and I Deriving sequential programs 8 9 I Set theory: , , , and ::: I Example: Sieve of Eratosthenes 2 ⊆ [ \ f g I Deriving concurrent programs I Specification languages: VDM, Z, B and TLA I Example: Sieve of Eratosthenes Reasoning about programs I Example: Communicating through a circular buffer I Hoare logic: p c q I Semantics of concurrent programs f g f g î ó I Refinement calculus or B or Event-B: , x : p ; q v I Rely/guarantee concurrency I Separation logic I Concurrent separation logic 3 / 1 4 / 1 Reasoning about (concurrent) software Compositional reasoning Our main tool is abstraction: Reasoning about the whole is decomposed into reasoning about the components sequential specify components using pre/post conditions Why? I Make reasoning tractable I e.g. sorting I Partition the work (e.g. for multiple people to work on different I precondition noduplicates(s) components) 0 0 I postcondition ordered(s ) items(s ) = items(s) I Avoid reasoning about paths ^ data use abstractions such as sets and maps j := 0; I decouple the specification of what the user sees from the while j = N do 6 implementation if p then s else t; I avoid the details of the implementations, such as, linked lists and j := j + 1 trees N process due to interference between processes need more than pre and post I 2 possible paths 5 / 1 6 / 1 Hoare logic is compositional Parallel composition Structured reasoning about programs Interference possible before or after every atomic step si and ti I Sequential composition s ; s ; ::: ; sn t ; t ; ::: ; tn 1 2 k 1 2 p s q q t r f g f g f g f g p s ; t r f g f g I The number of paths in terms of n explodes I While loop using a loop invariant p I If there is no interference between s and t p b s p p s q p t q f ^ g f g f 1g f 1g f 2g f 2g p while b do s p b p p s t q q f g f ^ : g f 1 ^ 2g k f 1 ^ 2g For termination one needs to add a loop variant or well-founded relation I But this is the easy case 7 / 1 8 / 1 Example: Sieve of Eratosthenes (sequential) REM(2) I Determine primes up to some given n I Illustrates: I starting with abstract type (a set) 1 2 3 4 5 6 7 8 9 10 11 12 ... I using guarantees (even for a sequential program) I introducing loops I data refinement to an array of small sets that can each fit in a word REM(3) 9 / 1 10 / 1 Specification in refinement calculus style Sieve of Eratosthenes - sequential Concrete syntax I Precondition s 2 :: n holds initially ⊆ I Assume that C is the set of all composite numbers (non-primes) 0 I Postcondition s = s C − VDM Refinement calculus î ó s : s 2 :: n ; s0 = s C ⊆ − SIEVE SIEVE =“ = equivalent post condition (set theory) î 0 ó î ó ext wr s : FN1 s 2 :: n s : s = s C s : s 2 :: n ; s0 s s s0 C s0 C = pre s 2 :: n f ⊆ g − ⊆ ⊆ ^ − ⊆ ^ \ ; ⊆ guarantee on every step post s0 = s C v î ó − (guar s0 s s s0 C) s : s 2 :: n ; s0 C = ⊆ ^ − ⊆ e ⊆ \ ; The guarantee condition is 0 0 0 I reflexive, i.e. s = s s s s s C 0 )00 ⊆ ^ 00− ⊆ 00 0 0 0 I transitive, i.e. s s s s s C s s C s s s s C ⊆ ⊆ ^ − ⊆ ^ − ⊆ ) ⊆ ^ − ⊆ 11 / 1 12 / 1 First some set theory Then some number theory Assume ci is the set of all multiples of i, excluding i s0 C = If 2 i 2 j and if i j n then either ≤ ^ ≤ ∗ ≤ 0 \ S ; 2 2 s j N 2 j cj = I i n j n or ≡ \ f 2 j ≤ · g ; S 0 2 ≤ ^ 2 ≥ j N 2 j (s cj ) = I j n i n ≡ f 2 j ≤ · 0 \ g ; j N 2 j s cj = ≤ ^ ≥ ≡ 8 2 · ≤ ) \ ; Hence one only has to remove multiples of i up to the (integer part of) the square Therefore root of i 2 0 0 s 0 :: n n i ( j 2 :: i s c = ) (guar s s s s C) e ⊆ ^ ≤ ^ 8 2 · \ j ; î ⊆ ^ − 0⊆ ó s : s 2 :: n ; s C = ) ⊆ \ ; ( j N 2 j s cj = ) by above set theory 8 2 · ≤ ) \ ; v 0 0 (guar s s s s C) e î ⊆ ^ − ⊆ ó The predicate ( j 2 :: i s cj = ) holds if i is 1 s : s 2 :: n ; j 2 j s0 c = 8 2 · \ ; ⊆ 8 · ≤ ) \ j ; The refinement now focuses on just the specification (the second line) 13 / 1 14 / 1 Introducing a loop Refining the loop body ñs 2 :: n (i + 1)2 n i < i0 ô i; s : ⊆ ^ ≤ ^ ; ^ 0 j 2 :: i s c = j 2 :: i s cj = 8 2 · \ j ; 8 2 · \ ; î ó introduce sequential composition s : s 2 :: n ; j 2 j s0 c = v ⊆ 8 · ≤ ) \ j ; i := i + 1; introduce variable i to be used as loop index ñ 2 ô v s 2 :: n i n var i := 1; s : ⊆ ^ ≤ ^ ; 0 j 2 :: i 1 s cj = j 2 :: i s cj = ñs 2 :: n n < (i + 1)2 ô 8 2 − · \ ; 8 2 · \ ; i; s : ⊆ ^ ; ^ j 2 :: i s c = j 2 :: i s0 c = Refining the specification: 8 2 · \ j ; j introduce while loop 8 2 · \ ; v 2 ñ 2 ô while(i + 1) n do s 2 :: n i n 0 ñ ≤ ô s : ⊆ ^ ≤ ^ ; j 2 :: i s cj = s 2 :: n (i + 1)2 n i < i0 j 2 :: i 1 s cj = 8 2 · \ ; i; s : ⊆ ^ ≤ ^ ; ^ 0 8 2 − · \ ; j 2 :: i s cj = j 2 :: i s cj = to achieve the post condition the elements in ci need to be removed 8 2 · \ ; 8 2 · \ ; v î 2 0 ó s : s 2 :: n i n ; s ci = ⊆ ^ ≤ \ ; recall that ci contains all the multiples of i, excluding i v î ó s : s 2 :: n i2 n ; j 2 i j i n j i s0 ⊆ ^ ≤ 8 · ∗ ≤ ∗ ≤ ) ∗ 62 Reminder: this is all in the context of (guar s0 s s s0 C) ⊆ ^ − ⊆ 15 / 1 16 / 1 Introduce inner loop Refine the inner loop body 2s 2 :: n 2 i k i n k < k 0 3 k; s : 6 j⊆ 2 i ^j ∗i <≤k ∗i ≤ ^ ; j 2 ^i j i < k i 7 î ó 4 5 s : s 2 :: n i2 n ; j 2 i j i n j i s0 8 · j ∗i ≤s ∗ ∗ ) 8 · j ∗i ≤s0∗ ∗ ) ⊆ ^ ≤ 8 · ∗ ≤ ∗ ≤ ) ∗ 62 ∗ 62 ∗ 62 introduce variable k to be used as a loop index introduce sequential composition v v var k := 2; 2s 2 :: n 2 i k i n 3 2 3 s 2 :: n i2 n n < k i 6 ⊆ ^ ∗ ≤ ∗ ≤ ^ 7 s : 4 j 2 i j i < k i ; j 2 i j i < (k + 1) i 5; 6 ⊆ ^ ≤ ^ ∗ ^ 7 8 · ∗ ≤ ∗ ∗ ) 8 · ∗ ≤ 0∗ ∗ ) k; s : 4 j 2 i j i < k i ; j 2 i j i < k i 5 j i s j i s 8 · ∗ ≤ ∗ ∗ ) 8 · ∗ ≤ 0∗ ∗ ) ∗ 62 ∗ 62 j i s j i s k := k + 1 ∗ 62 ∗ 62 introduce inner loop v while k i n do Now refine the specification ∗ 2≤ 0 3 s 2 :: n 2 i k i n k < k 2 3 k; s : 6 j⊆ 2 i ^j ∗i <≤k ∗i ≤ ^ ; j 2 ^i j i < k i 7 s 2 :: n 2 i k i n 48 · ∗ ≤ ∗ ∗ ) 8 · ∗ ≤ ∗ ∗ )5 6 ⊆ ^ ∗ ≤ ∗ ≤ ^ 7 j i s j i s0 s : 4 j 2 i j i < k i ; j 2 i j i < (k + 1) i 5 ∗ 62 ∗ 62 8 · j ∗i ≤s ∗ ∗ ) 8 · j ∗i ≤s0∗ ∗ ) ∗ 62 ∗ 62 to achieve the post condition the element k i must be removed v î ó ∗ s : s 2 :: n 2 i k i n ; k i s0 ⊆ ^ ∗ ≤ ∗ ≤ ∗ 62 17 / 1 18 / 1 Bring back the guarantee Remove an element from the set Define î ó Rem(m) = (guar s0 s s s0 m ) s : s 0 :: n m 0 :: n ; m s0 “ ⊆ ^ − ⊆ f g e ⊆ ^ 2 62 Now recall that this was all in the context of a guarantee. The code so far is 0 0 î 0ó (guar s s s s C) e s : s 2 :: n 2 i k i n ; k i s ⊆ ^ − ⊆ ⊆ ^ ∗ ≤ ∗ ≤ ∗ 62 var i := 1; strengthen guarantee and weaken precondition v î ó while(i + 1)2 n do (guar s0 s s s0 k i ) s : s 0 :: n k i 0 :: n ; k i s0 ≤ ⊆ ^ − ⊆ f ∗ g e ⊆ ^ ∗ 2 ∗ 62 i := i + 1; var k := 2; while k i n do Rem∗ (k≤ i); k := k +∗ 1 19 / 1 20 / 1 Data refinement: representing the set as an array of words Remove an element from the set Define î ó Rem(m) = (guar s0 s s s0 m ) s : s 0 :: n m 0 :: n ; m s0 “ ⊆ ^ − ⊆ f g e ⊆ ^ 2 62 † £ I A finite set contained in 0 :: n can be represented by a bit map of n + 1 bits Using the representation as an array v : array 0 :: n+1 1 of (0 :: ws 1) ws − − I Assume a word has ws bits 0 0 (guar retr(v ) retr(v) retr(v) retr(v ) m ) e I A word can represent a set with ws elements î ⊆ ^ − ⊆ó f g v : retr(v) 0 :: n m 0 :: n ; m retr(v 0) I A word can represent a set contained in the set 0 :: ws 1 ⊆ ^ 2 62 † n+1 £ − I For a large set one needs a vector v of ws words From the definition of retr I The function retr(v) retrieves the set represented by v m retr(v 0) (m mod ws) v 0(m div ws) 62 , 62 retr(v) = j 0 :: n (j mod ws) v(j div ws) “ f 2 j 2 g Hence the specification can be written as î ó v : retr(v) 0 :: n m 0 :: n ; (m mod ws) v 0(m div ws) ⊆ ^ 2 62 v î ó v(m div ws): m 0 :: n ; (m mod ws) v 0(m div ws) 2 62 21 / 1 22 / 1 Removing an element from a set represented as a single word Conclusions RemW (var w : F(0 :: ws 1); i : 0 :: ws 1) =“ 0 − 0 − (guar w w w w i ) e î ⊆ ^ − ⊆ f g ó w : w 0 :: ws 1 i 0 :: ws 1 ; i = w 0 ⊆ − ^ 2 − 2 I Importance of data abstraction Therefore I Guarantee allows one to focus on the interesting part Rem(m) v RemW (v(m div ws); m mod ws) RemW can be implemented using bit-wise operations on a word (exercise) 23 / 1 24 / 1 Example: Parallel SIEVE of Eratosthenes REM(2) I Determine primes up to some given n I Illustrates: ? I starting with abstract type I need1 to document2 3 interference4 5 6 (R)7 8 9 10 11 12 ..
Load more

Recommended publications
  • Calculi for Program Incorrectness and Arithmetic Philipp Rümmer
    Thesis for the Degree of Doctor of Philosophy Calculi for Program Incorrectness and Arithmetic Philipp R¨ummer Department of Computer Science and Engineering Chalmers University of Technology and G¨oteborg University SE-412 96 G¨oteborg Sweden G¨oteborg, 2008 Calculi for Program Incorrectness and Arithmetic Philipp R¨ummer ISBN 978-91-628-7242-7 c Philipp R¨ummer, 2008 Technical Report no. 50D Department of Computer Science and Engineering Research Group: Formal Methods Department of Computer Science and Engineering Chalmers University of Technology and G¨oteborg University SE-412 96 G¨oteborg, Sweden Telephone +46 (0)31–772 1000 Printed at Chalmers, G¨oteborg, 2008 II Abstract This thesis is about the development and usage of deductive methods in two main areas: (i) the deductive dis-verification of programs, i.e., how techniques for deductive verification of programs can be used to detect program defects, and (ii) reasoning modulo integer arithmetic, i.e., how to prove the validity (and, in special cases, satisfiability) of first-order formulae that involve integer arithmetic. The areas of program verification and of testing are traditionally considered as complementary: the former searches for a formal proof of program correctness, while the latter searches for witnesses of program incorrectness. Nevertheless, de- ductive verification methods can discover bugs indirectly: the failure to prove the absence of bugs is interpreted as a sign for the incorrectness of the program. This approach is bound to produce “false positives” and bugs can be reported also for correct programs. To overcome this problem, I investigate how techniques that are normally used for verification can be used to directly prove the incorrectness of programs.
    [Show full text]
  • Module COMP11212 Fundamentals of Computation
    Module COMP11212 Fundamentals of Computation Correctness, Complexity, and Computability (First Half of Notes) Giles Reger Semester 2, 2017 Organisation and Learning Outcomes Structure, Assessment, Coursework All of this information is the same as for Part 1 and you should refer to those notes for the details. Assumptions This course requires a certain level of mathematical skill; indeed one of the goals is to show that there is a use for much of the discrete mathematics that you are taught elsewhere. Chapter 0 attempts to gather the assumed material together but you should also cross-reference material on discrete mathematics or use the web to look up unfamiliar concepts. These Notes This part of the course is divided up into four main chapters. Before they start there is an introduction to the Part which gives a high-level overview of the contents - I strongly suggest reading this. Important Read the introduction. I use these boxes to highlight things that are important that you may miss when scanning through the notes quickly. Typically the box will repeat something that has already been said. In this case, read the introduction! i ii Chapter 0 recaps some mathematical material from COMP11120. Then the main four chapters cover the four main concepts of models of compu- tation, correctness, complexity and computability. There are examples and exercises throughout the notes. The assessed exercises for the examples classes are outlined in question sheets at the end of the notes. Some exam- ples are marked with a (*) indicating that they go significantly beyond the examined material. Confused? Great! Learning theory tells us that we do the best learning when we are confused by something and resolve that confusion.
    [Show full text]
  • Extending Dynamic Invariant Detection with Explicit Abstraction
    EXTENDING DYNAMIC INVARIANT DETECTION WITH EXPLICIT ABSTRACTION by DANIEL BRIAN KEITH A DISSERTATION Presented to the Department of Computer and Information Science and the Graduate School of the University of Oregon in partial fulfillment of the requirements for the degree of Doctor of Philosophy March 2012 DISSERTATION APPROVAL PAGE Student: Daniel Brian Keith Title: Extending Dynamic Invariant Detection with Explicit Abstraction This dissertation has been accepted and approved in partial fulfillment of the requirements for the Doctor of Philosophy degree in the Department of Computer and Information Science by: Michal Young Chair Zena Ariola Member Christopher Wilson Member Edward Vogel Outside Member and Kimberly Andrews Espy Vice President for Research & Innovation/ Dean of the Graduate School Original approval signatures are on file with the University of Oregon Graduate School. Degree awarded March 2012 ii c 2012 Daniel Brian Keith iii DISSERTATION ABSTRACT Daniel Brian Keith Doctor of Philosophy Department of Computer and Information Science March 2012 Title: Extending Dynamic Invariant Detection with Explicit Abstraction Dynamic invariant detection is a software analysis technique that uses traces of function entry and exit from executing programs and infers partial specifications that characterize the observed behavior. The specifications are reported as logical precondition and postcondition expressions (invariants) that relate arguments, instance variables, and results. Detectors typically generate large collections of invariants, among which most are true but few are interesting or useful. Refining this flood of invariants into a useful subset often requires manual tuning through configuration options and modification of the program under analysis. Our research asks whether we can improve dynamic invariant detection by enabling explicit abstractions to be declared and applied to a program under analysis and whether this is practical; this dissertation shows that it is indeed practical and useful.
    [Show full text]
  • Dynamic Logic for an Intermediate Language: Verification, Interaction
    Dynamic Logic for an Intermediate Language Verification, Interaction and Refinement zur Erlangung des akademischen Grades eines Doktors der Naturwissenschaften von der Fakultat¨ fur¨ Informatik des Karlsruher Instituts fur¨ Technologie (KIT) genehmigte Dissertation von Mattias Ulbrich aus Ludwigsburg Tag der mundlichen¨ Prufung:¨ 17. Juni 2013 Erster Gutachter: Prof. Dr. Peter H. Schmitt Karlsruher Institut fur¨ Technologie Zweite Gutachterin: Assoc. Prof. Dr. Marieke Huisman University of Twente Acknowledgements I would not have been able to compose this thesis without the help of many who contributed to it in various ways. First and foremost, I would like to express my special appreciation and gratitude to my advisor Professor Dr. Peter H. Schmitt for giving me the opportunity to undertake this dissertation project, for his continuous scientific advice and support, and for granting me so much freedom in my research. His gentle way of leading the group always made me feel at home. I am thankful to my second reviewer Assoc. Prof. Dr. Marieke Huisman for the time and energy she invested into fulfilling this role. My thanks go also to Juniorprofessor Dr. Mana Taghdiri and Professor Dr. Jorn¨ Muller-Quade¨ for their service as examiners in the defense committee. I have always very much enjoyed working together with my colleagues in the formal method groups at KIT. We had plenty of inspiring discussions, an excellent teamwork and lots of fun. My thanks go to my former colleagues Dr. Christian Engel, Dr. Benjamin Weiß and Dr. Frank Werner as well as to my current fellow researchers Thorsten Bormer, Daniel Bruns, Aboubakr Achraf El Ghazi, Dr.
    [Show full text]
  • A Systematic Derivation of Loop Specifications Using Patterns Aditi Barua University of Texas at El Paso, [email protected]
    University of Texas at El Paso DigitalCommons@UTEP Departmental Technical Reports (CS) Department of Computer Science 12-2015 A Systematic Derivation of Loop Specifications Using Patterns Aditi Barua University of Texas at El Paso, [email protected] Yoonsik Cheon University of Texas at El Paso, [email protected] Follow this and additional works at: http://digitalcommons.utep.edu/cs_techrep Part of the Programming Languages and Compilers Commons, and the Software Engineering Commons Comments: Technical Report: UTEP-CS-15-90 Recommended Citation Barua, Aditi and Cheon, Yoonsik, "A Systematic Derivation of Loop Specifications Using Patterns" (2015). Departmental Technical Reports (CS). Paper 988. http://digitalcommons.utep.edu/cs_techrep/988 This Article is brought to you for free and open access by the Department of Computer Science at DigitalCommons@UTEP. It has been accepted for inclusion in Departmental Technical Reports (CS) by an authorized administrator of DigitalCommons@UTEP. For more information, please contact [email protected]. A Systematic Derivation of Loop Specifications Using Patterns Aditi Barua and Yoonsik Cheon TR #15-90 December 2015 Keywords: formal proof, functional program verification, intended function, program specification, specification pattern, while statement 1998 CR Categories: D.2.4 [Software Engineering] Requirements/Specifications — languages; D.2.4 [Software Engineering] Software/Program Verification — correctness proofs, formal methods; D.3.3 [Programming Languages] Language Constructs and Features — control structures; F.3.1 [Logics and Meanings of Programs] Specifying and Verifying and Reasoning about Programs — logics of programs, specification techniques. Department of Computer Science The University of Texas at El Paso 500 West University Avenue El Paso, Texas 79968-0518, U.S.A.
    [Show full text]
  • Theory of Programs Bertrand Meyer
    Draft 3, 6 December 2015 Theory of Programs Bertrand Meyer While the theoretical study of programs fills volumes, a handful of concepts from elementary set theory suffice to establish a clear and practical basis. Among the results: • To describe a specification or a program, it suffices to define one relation and one set. • To describe the concepts of programming, concurrent as well as sequential, three elementary operations on sets and relations suffice: union, composition and restriction. • These techniques suffice to derive the axioms of classic papers on the “laws of programming” as straightforward consequences. • To define both program correctness and refinement, the ordinary subset operator “⊆” suffices. Paragraphs labeled “Intuition” relate the concepts to the experience of readers having done some programming. Readers familiar with other views of theoretical informatics will find comparisons in “Comment” paragraphs. Section 5 provides more discussion. 1 Programs A program is a mathematical object: a constrained relation over a set of states. Definition: program, specification, precondition, postcondition. A program, also known as a specification, over a state set S, consists of: • A relation post: S ↔ S, the program’s postcondition. •A set Pre ⊆ S, the program’s precondition. Notation: A ↔ B is the set of binary relations between A and B, that is, P (A × B). The domain of a relation r is written r and its range r . Intuition: a program starts from a certain state and produces one of a set of possible states satis- fying properties represented by post. Pre tells us which states are acceptable as initial states. In the general case, more than one resulting state can meet the expectation expressed by post.
    [Show full text]
  • ACSL: ANSI/ISO C Specification Language
    ACSL: ANSI/ISO C Specification Language ACSL: ANSI/ISO C Specification Language Version 1.4 Patrick Baudin1, Pascal Cuoq1, Jean-Christophe Filliâtre4;3, Claude Marché3;4, Benjamin Monate1, Yannick Moy2;4;3, Virgile Prevosto1 1 CEA LIST, Software Reliability Laboratory, Saclay, F-91191 2 France Télécom, Lannion, F-22307 3 INRIA Saclay - Île-de-France, ProVal, Orsay, F-91893 4 LRI, Univ Paris-Sud, CNRS, Orsay, F-91405 c 2009-2010 CEA LIST and INRIA This work has been supported by the ‘CAT’ ANR project (ANR-05-RNTL-0030x) and by the ANR CIFRE contract 2005/973. CONTENTS Contents 1 Introduction 11 1.1 Organization of this document........................... 11 1.2 Generalities about Annotations.......................... 11 1.2.1 Kinds of annotations............................ 12 1.2.2 Parsing annotations in practice...................... 12 1.2.3 About preprocessing............................ 12 1.2.4 About keywords.............................. 13 1.3 Notations for grammars.............................. 13 2 Specification language 15 2.1 Lexical rules..................................... 15 2.2 Logic expressions.................................. 16 2.2.1 Operators precedence........................... 18 2.2.2 Semantics.................................. 19 2.2.3 Typing.................................... 19 2.2.4 Integer arithmetic and machine integers................. 20 2.2.5 Real numbers and floating point numbers................ 22 2.2.6 Structures, Unions and Arrays in logic.................. 25 2.2.7 String literals................................ 27 2.2.8 Address operator.............................. 27 2.2.9 Function pointers.............................. 27 2.3 Function contracts................................. 27 2.3.1 Built-in constructs \old and \result .................... 28 2.3.2 Simple function contracts......................... 28 2.3.3 Contracts with named behaviors..................... 30 2.3.4 Memory locations.............................
    [Show full text]
  • Verification of Goroutines Using Why3 Radboud University Nijmegen
    Master’s Thesis Verification of Goroutines using Why3 Marc Schoolderman July 2016 supervisor: dr. F. Wiedijk second reader: dr. F. Verbeek Radboud University Nijmegen Institute for Computing and Information Sciences Abstract Concurrent software has become increasingly important in today’s world; but reasoning formally about such programs is hard. The programming language Go offers a paradigm for writing programs that do not rely on memory sharing as a primary means of communication between processes. While this should make it easier to reason about concurrency, methods for formal verification of programs written in Go are absent. In this thesis, we will investigate the capabilities of the Why3 verification platform to fill this gap. We first apply it to verify the complexity of heapsort, check an early program proof by Alan Turing, and solve other logical problems. We then use it as the foundation of a verification method for concurrent Go programs. With this method, we can verify partial correctness and liveness properties for concurrent programs written in a small subset of Go, using a high degree of automation. This technique is designed to be implementable as a tool, which could — if extended further — allow the partial verification of a larger range of Go programs. Contents 1. Introduction 6 1.1. Computer-aided reasoning....................................6 1.2. Software analysis toolchains...................................7 1.3. Concurrent programming.....................................8 1.4. Research question.........................................9 1.4.1. Reproducibility of results................................9 1.5. A verification primer........................................ 10 2. The Why3 verification platform 12 2.1. Overview of Why3 ......................................... 12 2.2. The Why language......................................... 15 2.2.1.
    [Show full text]