Using Spin to Help Teach Concurrent Programming
|
|
- Magdalene Thompson
- 5 years ago
- Views:
Transcription
1 Using Spin to Help Teach Concurrent Programming John Regehr May 1, Introduction and Motivation Writing correct concurrent programs is very difficult; race conditions, deadlocks, and livelocks can be hard to discover by inspection and may lurk undetected for long periods of time. The following observation was made about errors that occur in communication protocols; it applies equally well to errors in nondistributed concurrent programs: Such errors, while rare, do occur, and their rareness will make it extremely difficult to catch the flaw in the system. This inadequate scheme will work almost all of the time. This document accepts as a given that the goal of an undergraduate operating systems course is to teach the principles of concurrent programming, as well as the design and implementation of real operating systems. I will argue that the former is very difficult to teach well, and that it can be taught better with the help of a system that can be used to model and prove properties about concurrent programs. 2 What s Wrong with Nachos and Minix Nachos [1], Minix [5], and XINU [2] are operating systems designed to teach operating systems. The premise is that a simplified system will contain the essential structure, without bogging students down with the irrelevant details that pervade a real OS. This logic is sound with respect to teaching operating systems design and implementation; however, it does not carry over to teaching concurrent programming, which the student is usually expected to pick up along the with rest. For example, we find the following quote in [1]: When we first used Nachos, we omitted many of the practice problems we now include, thinking that students would see enough concurrency in the rest of the project. In retrospect, the result was that many students were still making concurrency errors even in the final phase of the project. 1
2 3 MODELING CONCURRENT SYSTEMS: SPIN 2 The usual procedure is for students to write a number of concurrent programs, test them, and turn them in for grading by inspection or further testing. I believe that this sends a very bad message: that a few (or even many) apparently-correct runs and the inspection of a competent programmer mean that a program is correct. This is simply not true in concurrent programming, an area so difficult that many incorrect results have been published and gone undetected for some time. One way to avoid misleading students about the difficulty of the task is to have them prove that their programs are correct this is the approach advocated by Dijkstra in [3]. To avoid the pain of proving properties of programs by hand, we use a system called Spin, which is designed to prove properties about models of concurrent programs. 3 Modeling Concurrent Systems: Spin Spin [4] allows us create a model of a concurrent system which is simple enough to prove things about, but detailed enough to map easily to a real system. Spin was designed for communication protocol analysis, but works just as well for processes communicating through shared memory. It performs an exhaustive search of the state-space of a group of processes. Although this is PSPACE hard and does not work for large models, the programs under consideration here are well within its reach. The exhaustive-search approach has the useful property that it will either prove some property about the entire state-space, or come up with an execution that violates the property a counterexample. Spin models are written in Promela, a simple C-like language. It has three language constructs specifically designed for validation of programs: an assert statement that can be used to express invariants, three kinds of labels useful for proving deadlock and livelock freedom, and general temporal logic claims. For purposes of this paper we are only interested in the first two, since they allow us to prove all of the properties that we are interested in. Because Spin makes races, deadlocks, and livelocks easily detectable it allows us to completely avoid the unfortunate (but common) situation in which a student implements a solution to (for example) the dining philosophers problem, runs it successfully a few times, and after handing it in is unpleasantly surprised to be graded off for having an incorrect program. Even worse, the grader may fail to notice the error, allowing the student to escape with the feeling that he or she knows how to write a correct concurrent program. This can easily happen since some students inevitably implement convoluted solutions with more semaphores than necessary; these defy analysis and the only solution is to take off points or ask for a resubmission. Spin indirectly deters overly complicated solutions by being unable to prove that they are correct (or incorrect).
3 4 LESSON PLAN 3 4 Lesson Plan I have created two homework assignments using Spin; presumably they would be used in combination with Nachos or Minix assignments. Students should be introduced to Spin with one or two lectures; there is a large amount of Spin documentation in Holzmann s book [4] and at the Spin web site: 5 Assignment 1: Mutual Exclusion The purpose of this assignment is to introduce you to Spin, and to programming in Promela. You will need access to a machine with Spin and XSpin version or newer installed. Included in the Spin package is some documentation in HTML; to do this assignment you will want to refer to this and to ch. 5 of Holzmann s book (available in postscript from the Spin homepage). 5.1 A Buggy Mutual Exclusion Algorithm The following program creates two processes, each of which repeatedly executes the critical section. If both processes can be in the critical section at the same time, the assertion will fail. byte in; bool lock; active [2] proctype user() L1: /* wait for lock to be free */ (lock == 0); /* grab the lock */ lock = 1; /* critical section */ in++; assert (in == 1); in--; /* release the lock */ lock = 0; goto L1;
4 5 ASSIGNMENT 1: MUTUAL EXCLUSION 4 The program clearly contains a race condition, since both processes may see that the lock is free and enter the critical section simultaneously. Verify this using XSpin: under the Run menu, select Set verification parameters. Make sure that Spin is checking for assertion violations, and then do a verification run. Spin will offer to run a guided simulation showing an execution that violates an assertion. Run this simulation; make sure you understand it, and include a copy of its output in your homework. 5.2 Fixing the Problem One way to perform actions atomically in Spin is to simply tell Spin to do so. Modify the program from the last part by putting the code that tests and grabs the lock inside an atomic... block. Run a verification on the modified program to prove that the assertion can never be violated. Include a copy of the modified program and the verification output with your assignment. Note that using atomic, we could eliminate the lock variable and just atomically execute the critical section itself. 5.3 Another Buggy Mutual Exclusion Algorithm Although the atomic construct provides a convenient way to execute a group of operations atomically, real computers have no such primitive. Therefore, there are many algorithms designed to implement mutual exclusion using only basic atomic operations such as memory references. Try to find a situation in which the following algorithm does not guarantee mutual exclusion: byte in; byte x, y, z; active [2] proctype user() byte me = _pid+1; /* me is 1 or 2 */ L1: x = me; L2: if :: (y!= 0 && y!= me) -> goto L1 /* try again */ :: (y == 0 y == me) fi; L3: z = me; L4: if :: (x!= me) -> goto L1 /* try again */ :: (x == me) fi; L5: y = me;
5 5 ASSIGNMENT 1: MUTUAL EXCLUSION 5 L6: if :: (z!= me) -> goto L1 /* try again */ :: (z == me) fi; L7: /* success */ /* critical section */ in = in+1; assert(in == 1); in = in - 1; goto L1 Now, use Spin to find a counterexample, and include it in what you turn in. Also explain in your own words what went wrong. 5.4 Another Real Algorithm Implement the following 2-process mutual exclusion algorithm (from p. 143 of Silberschatz and Galvin) in Promela without using atomic. i is the id of the running process, and is either 0 or 1. bool flag[2]; bool turn; while (TRUE) flag[i] = TRUE; turn = 1-i; while (flag[1-i] && turn == i-1) /* critical section */ flag[i] = FALSE; Prove that it enforces mutual exclusion; include a copy of your implementation along with Spin output verifying it in what you turn in. Hand in a report with the following clearly labelled items: 1. guided simulation output showing an assertion violation in the first broken algorithm 2. your fixed program 3. verification output showing that the fixed program is correct
6 6 ASSIGNMENT 2: DINING PHILOSOPHERS 6 4. a counterexample to the second broken mutual exclusion algorithm, and an explanation of what went wrong 5. a Promela implementation of the mutual exclusion algorithm from Silberschatz and Galvin p. 143, and Spin output demonstrating that mutual exclusion is guaranteed 6 Assignment 2: Dining Philosophers In the last assignment, we assumed that the algorithms were correct if they did not violate mutual exclusion. In general, however, this is not enough: a correct concurrent algorithm must also be provably free of deadlocks and livelocks. Spin assumes that a program has deadlocked if there are no runnable processes. To detect livelock, we can mark statements which, when executed, indicate that the program is making progress. Spin can be used to prove that a program must make progress infinitely often, and is therefore free of nonprogress cycles. See Ch. 6 of the Holzmann book for more details. 6.1 A Simple Solution The following Promela program models a solution to the dining philosophers problem. Note that the solution is almost trivially correct since we pick up both chopsticks and begin eating atomically. Also note the technique for verifying that the problem is solved correctly: we start a monitor process for each philosopher that asserts that either it isn t eating, or it is eating, possesses both chopsticks, and neither neighbor is eating. Because the monitors can run at any time, they cause Spin to prove that they are always true. The progress: labels tell Spin that we consider the program to be making progress when philosophers are eating. We use a different label for each philosopher to prove a weak kind of fairness: every philosopher must eat infinitely often (a single progress: label would only ensure that some philosopher must eat infinitely often). #define NUM 5 byte chopstick[num]; byte eating[num]; active [NUM] proctype philo () L1: /* grab both chopsticks atomically */ atomic (chopstick[_pid] == 0 && chopstick[(_pid+1)%num] == 0); chopstick[_pid] = 1; chopstick[(_pid+1)%num] = 1;
7 6 ASSIGNMENT 2: DINING PHILOSOPHERS 7 eating[_pid] = 1; printf ("%d eating\n", _pid); /* eating */ if :: (_pid == 0) -> progress0: skip; :: (_pid == 1) -> progress1: skip; :: (_pid == 2) -> progress2: skip; :: (_pid == 3) -> progress3: skip; :: (_pid == 4) -> progress4: skip; fi; /* it s not really necessary to release them atomically */ atomic eating[_pid] = 0; chopstick[_pid] = 0; chopstick[(_pid+1)%num] = 0; goto L1; active [NUM] proctype monitor () assert ((!eating[_pid-num]) (eating[_pid-num] && chopstick[_pid-num] && chopstick[(_pid-num+1)%num] &&!eating[(_pid-num+1)%num] &&!eating[(_pid-num-1+num)%num]) ); Use Spin to verify that this program violates no assertions, and that it contains no deadlocks or non-progress cycles. 6.2 Better Solutions On p. 160, Silberschatz and Galvin suggest three solutions to the dining philosopher problem. The program in part 1 uses a critical section to pick up both chopsticks atomically. Modify the program to model the other two solutions; that is, (1) to allow at most 4 philosophers at the table at a time, and (2) to
8 7 CONCLUSIONS 8 have even- and odd-numbered philosophers pick up the chopsticks in different orders. Do not modify the monitor processes; use them, with Spin, to prove that your solutions are correct, and that they contain no deadlocks or non-progress cycles; include the Spin output in what you hand in. WARNING: The more complicated your solutions are, the less likely they are to work, and the longer Spin will take to verify them. If you think your solutions are as simple as you can make them and Spin still runs out of memory or fails to terminate, you may reduce the number of philosophers to 4 (indicate on your output that you have done so). Hand in a report with the following clearly labelled items: 1. two dining philosopher solutions, commented to the point that it is obvious what is going on 2. Spin output showing that your solutions are correct (that they do not violate any assertions, and contains no deadlocks or livelocks); you should run two verifications on each of the two programs 7 Conclusions Using Spin to teach concurrent programming has some obvious benefits: students need not worry about handing in an incorrect program since Spin will tell them if it works or not. When programs don t work, Spin will give a counterexample that the student can examine. Spin encourages experimentation because it is fast and easy to run. Finally, since they are forced to formally specify the correctness requirements for their programs, students will presumably gain a better understanding of what it means to write a correct concurrent program. A Solutions to Assignment 1 Guided simulation output showing an assertion violation: preparing trail, please wait...done 1: proc 1 (user) line 9 "pan_in" (state 1) [((lock==0))] 2: proc 0 (user) line 9 "pan_in" (state 1) [((lock==0))] 3: proc 1 (user) line 12 "pan_in" (state 2) [lock = 1] 4: proc 1 (user) line 15 "pan_in" (state 3) [in = (in+1)] 5: proc 0 (user) line 12 "pan_in" (state 2) [lock = 1] 6: proc 0 (user) line 15 "pan_in" (state 3) [in = (in+1)] Spin: line 16 "pan_in", Error: assertion violated #processes: 2 7: proc 1 (user) line 16 "pan_in" (state 4) 7: proc 0 (user) line 16 "pan_in" (state 4) 2 processes created
9 A SOLUTIONS TO ASSIGNMENT 1 9 Exit-Status 0 The fixed program: byte in; bool lock; active [2] proctype user() L1: /* atomically, wait for lock to be free and grab it */ atomic (lock == 0); lock = 1; /* critical section */ in++; assert (in == 1); in--; /* release the lock */ lock = 0; goto L1; Results of the successful verification run: (Spin Version April 1998) + Partial Order Reduction Full statespace search for: never-claim - (not selected) assertion violations + cycle checks - (disabled by -DSAFETY) invalid endstates + State-vector 16 byte, depth reached 5, errors: 0 9 states, stored 2 states, matched 11 transitions (= stored+matched) 2 atomic steps hash conflicts: 1 (resolved) (max size 2^19 states) memory usage (Mbyte)
10 A SOLUTIONS TO ASSIGNMENT 1 10 Counterexample: preparing trail, please wait...done 1: proc 1 (user) line 7 "pan_in" (state 1) [x = me] 2: proc 1 (user) line 10 "pan_in" (state 4) [(((y==0) (y==me)))] 3: proc 1 (user) line 12 "pan_in" (state 7) [z = me] 4: proc 1 (user) line 15 "pan_in" (state 10) [((x==me))] 5: proc 0 (user) line 7 "pan_in" (state 1) [x = me] 6: proc 0 (user) line 10 "pan_in" (state 4) [(((y==0) (y==me)))] 7: proc 1 (user) line 17 "pan_in" (state 13) [y = me] 8: proc 1 (user) line 20 "pan_in" (state 16) [((z==me))] 9: proc 1 (user) line 25 "pan_in" (state 19) [in = (in+1)] 10: proc 0 (user) line 12 "pan_in" (state 7) [z = me] 11: proc 0 (user) line 15 "pan_in" (state 10) [((x==me))] 12: proc 0 (user) line 17 "pan_in" (state 13) [y = me] 13: proc 0 (user) line 20 "pan_in" (state 16) [((z==me))] 14: proc 0 (user) line 25 "pan_in" (state 19) [in = (in+1)] Spin: line 26 "pan_in", Error: assertion violated #processes: 2 15: proc 1 (user) line 26 "pan_in" (state 20) 15: proc 0 (user) line 26 "pan_in" (state 20) 2 processes created Exit-Status 0 The mutex algorithm from S&G p. 143: #define TRUE 1 #define FALSE 0 bool flag[2]; bool turn; int in; active [2] proctype user () L1: flag[_pid] = TRUE; turn = 1-_pid; (flag[1-_pid] == FALSE turn!= 1-_pid); /* critical section */ in++; assert (in == 1); in--;
11 B SOLUTIONS TO ASSIGNMENT 2 11 flag[_pid] = FALSE; goto L1; Spin output: Spin Version April 1998) + Partial Order Reduction Full statespace search for: never-claim - (not selected) assertion violations + cycle checks - (disabled by -DSAFETY) invalid endstates + State-vector 24 byte, depth reached 23, errors: 0 38 states, stored 27 states, matched 65 transitions (= stored+matched) 0 atomic steps hash conflicts: 7 (resolved) (max size 2^19 states) memory usage (Mbyte) B Solutions to Assignment 2 Spin output omitted, but these programs were proven to be correct. This program only allows N 1 philosophers at the table at a time: #define NUM 5 bool chopstick[num]; bool eating[num]; byte at_table; active [NUM] proctype philo () L1: /* we can only sit down if the number of sitting philosophers will be NUM-1 or less */ atomic (at_table < (NUM-1)); at_table++;
12 B SOLUTIONS TO ASSIGNMENT 2 12 printf ("%d is at the table\n", _pid); atomic (chopstick[_pid] == 0); chopstick[_pid] = 1; atomic (chopstick[(_pid+1)%num] == 0); chopstick[(_pid+1)%num] = 1; eating[_pid] = 1; printf ("%d eating\n", _pid); /* eating */ if :: (_pid == 0) -> progress0: skip; :: (_pid == 1) -> progress1: skip; :: (_pid == 2) -> progress2: skip; :: (_pid == 3) -> progress3: skip; :: (_pid == 4) -> progress4: skip; fi; eating[_pid] = 0; chopstick[_pid] = 0; chopstick[(_pid+1)%num] = 0; at_table--; printf ("%d left the table\n", _pid); goto L1; active [NUM] proctype monitor () assert ((!eating[_pid-num]) (eating[_pid-num] && chopstick[_pid-num] && chopstick[(_pid-num+1)%num] &&!eating[(_pid-num+1)%num] &&!eating[(_pid-num-1+num)%num]) );
13 B SOLUTIONS TO ASSIGNMENT 2 13 This program has even-numbered philosophers pick up the left chopstick and then the right, and vice-versa for odd-numbered philosophers. #define NUM 4 bool chopstick[num]; bool eating[num]; active [NUM] proctype philo () L1: /* even philosophers pick up left, then right odd philosophers pick up right, then left */ if :: (_pid%2 == 0) -> atomic (chopstick[_pid] == 0); chopstick[_pid] = 1; atomic (chopstick[(_pid+1)%num] == 0); chopstick[(_pid+1)%num] = 1; :: (_pid%2 == 1) -> atomic (chopstick[(_pid+1)%num] == 0); chopstick[(_pid+1)%num] = 1; atomic (chopstick[_pid] == 0); chopstick[_pid] = 1; fi; eating[_pid] = 1; printf ("%d eating\n", _pid); /* eating */ if :: (_pid == 0) -> progress0: skip; :: (_pid == 1) -> progress1: skip; :: (_pid == 2) -> progress2: skip; :: (_pid == 3) -> progress3: skip;
14 REFERENCES 14 :: (_pid == 4) -> progress4: skip; fi; eating[_pid] = 0; chopstick[_pid] = 0; chopstick[(_pid+1)%num] = 0; goto L1; active [NUM] proctype monitor () assert ((!eating[_pid-num]) (eating[_pid-num] && chopstick[_pid-num] && chopstick[(_pid-num+1)%num] &&!eating[(_pid-num+1)%num] &&!eating[(_pid-num-1+num)%num]) ); References [1] Wayne A. Christopher, Steven J. Procter, and Thomas E. Anderson. The Nachos Instructional Operating System. Computer Science Division, University of California at Berkeley. [2] Douglas E. Comer. Operating Systems Design: The XINU Approach. Prentice Hall, [3] Edsger W. Dijkstra. On the cruelty of really teaching computing science. Communications of the ACM, 32(12), December [4] Gerard J. Holzmann. Design and Validation of Computer Protocols. Prentice Hall, [5] Andrew S. Tannenbaum. Operating Systems: Design and Implementation. Prentice Hall, 1987.
The SPIN Model Checker
The SPIN Model Checker Metodi di Verifica del Software Andrea Corradini Lezione 1 2013 Slides liberamente adattate da Logic Model Checking, per gentile concessione di Gerard J. Holzmann http://spinroot.com/spin/doc/course/
More informationThe Spin Model Checker : Part I/II
The Spin Model Checker : Part I/II Moonzoo Kim CS Dept. KAIST Korea Advanced Institute of Science and Technology Motivation: Tragic Accidents Caused by SW Bugs 2 Cost of Software Errors June 2002 Software
More informationDistributed Systems Programming (F21DS1) SPIN: Formal Analysis I
Distributed Systems Programming (F21DS1) SPIN: Formal Analysis I Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview Introduce
More informationPatrick Trentin Formal Methods Lab Class, Feb 26, 2016
Spin: Introduction Patrick Trentin patrick.trentin@unitn.it http://disi.unitn.it/~trentin Formal Methods Lab Class, Feb 26, 2016 These slides are derived from those by Stefano Tonetta, Alberto Griggio,
More informationPatrick Trentin Formal Methods Lab Class, March 03, 2017
Spin: Introduction Patrick Trentin patrick.trentin@unitn.it http://disi.unitn.it/trentin Formal Methods Lab Class, March 03, 2017 These slides are derived from those by Stefano Tonetta, Alberto Griggio,
More informationSPIN: Introduction and Examples
SPIN: Introduction and Examples Alessandra Giordani agiordani@disi.unitn.it http://disi.unitn.it/~agiordani Formal Methods Lab Class, September 28, 2014 *These slides are derived from those by Stefano
More informationMP 6 Modeling in Promela and SPIN
MP 6 Modeling in Promela and SPIN CS 477 Spring 2018 Revision 1.0 Assigned April 23, 2018 Due May 2, 2018, 9:00 PM Extension 48 hours (penalty 20% of total points possible) 1 Change Log 1.0 Initial Release.
More informationInterprocess Communication By: Kaushik Vaghani
Interprocess Communication By: Kaushik Vaghani Background Race Condition: A situation where several processes access and manipulate the same data concurrently and the outcome of execution depends on the
More informationProving Dekker with SPIN and PROMELA
15-410...fairness disabled... Proving Dekker with SPIN and PROMELA Joshua Wise With help from Greg Hartman L36_SPIN 1 Synchronization Project 4 due Wednesday Everyone having fun? Kernel interviews If you
More informationThe SPIN Model Checker
The SPIN Model Checker Metodi di Verifica del Software Andrea Corradini GianLuigi Ferrari Lezione 3 2011 Slides per gentile concessione di Gerard J. Holzmann 2 the do-statement do :: guard 1 -> stmnt 1.1
More informationTool demonstration: Spin
Tool demonstration: Spin 1 Spin Spin is a model checker which implements the LTL model-checking procedure described previously (and much more besides). Developed by Gerard Holzmann of Bell Labs Has won
More informationChapter 5: Process Synchronization. Operating System Concepts Essentials 2 nd Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationINF5140: Specification and Verification of Parallel Systems
INF5140: Specification and Verification of Parallel Systems Lecture 09 Defining Correctness Claims Gerar Schneider Department of Informatics University of Oslo INF5140, Spring 2007 Gerar Schneider (Ifi,
More informationOperating Systems. Designed and Presented by Dr. Ayman Elshenawy Elsefy
Operating Systems Designed and Presented by Dr. Ayman Elshenawy Elsefy Dept. of Systems & Computer Eng.. AL-AZHAR University Website : eaymanelshenawy.wordpress.com Email : eaymanelshenawy@yahoo.com Reference
More informationThe Design of a Distributed Model Checking Algorithm for Spin
The Design of a Distributed Model Checking Algorithm for Spin Gerard J. Holzmann http://eis.jpl.nasa.gov/lars http://spinroot.com/gerard/ Presented at FMCAD 2006, San Jose, California November 14, 2006
More informationProcess Synchronization
CSC 4103 - Operating Systems Spring 2007 Lecture - VI Process Synchronization Tevfik Koşar Louisiana State University February 6 th, 2007 1 Roadmap Process Synchronization The Critical-Section Problem
More informationIntroduction to Linear-Time Temporal Logic. CSE 814 Introduction to LTL
Introduction to Linear-Time Temporal Logic CSE 814 Introduction to LTL 1 Outline Motivation for TL in general Types of properties to be expressed in TL Structures on which LTL formulas are evaluated Syntax
More informationRoadmap. Readers-Writers Problem. Readers-Writers Problem. Readers-Writers Problem (Cont.) Dining Philosophers Problem.
CSE 421/521 - Operating Systems Fall 2011 Lecture - X Process Synchronization & Deadlocks Roadmap Classic Problems of Synchronization Readers and Writers Problem Dining-Philosophers Problem Sleeping Barber
More informationA Tutorial on Model Checker SPIN
A Tutorial on Model Checker SPIN Instructor: Hao Zheng Department of Computer Science and Engineering University of South Florida Tampa, FL 33620 Email: haozheng@usf.edu Phone: (813)974-4757 Fax: (813)974-5456
More informationChapter 6: Synchronization. Operating System Concepts 8 th Edition,
Chapter 6: Synchronization, Silberschatz, Galvin and Gagne 2009 Outline Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization
More informationSPIN, PETERSON AND BAKERY LOCKS
Concurrent Programs reasoning about their execution proving correctness start by considering execution sequences CS4021/4521 2018 jones@scss.tcd.ie School of Computer Science and Statistics, Trinity College
More informationCS153: Deadlock. Chengyu Song. Slides modified from Harsha Madhyvasta, Nael Abu-Ghazaleh, and Zhiyun Qian
1 CS153: Deadlock Chengyu Song Slides modified from Harsha Madhyvasta, Nael Abu-Ghazaleh, and Zhiyun Qian 2 Administrivia Lab Lab1 is due this Sunday Demo sessions next week Little book of semaphores First
More informationChapter 6: Process Synchronization. Operating System Concepts 8 th Edition,
Chapter 6: Process Synchronization, Silberschatz, Galvin and Gagne 2009 Module 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores
More informationSynchronization. CS 475, Spring 2018 Concurrent & Distributed Systems
Synchronization CS 475, Spring 2018 Concurrent & Distributed Systems Review: Threads: Memory View code heap data files code heap data files stack stack stack stack m1 m1 a1 b1 m2 m2 a2 b2 m3 m3 a3 m4 m4
More informationComputer Lab 1: Model Checking and Logic Synthesis using Spin (lab)
Computer Lab 1: Model Checking and Logic Synthesis using Spin (lab) Richard M. Murray Nok Wongpiromsarn Ufuk Topcu Calornia Institute of Technology AFRL, 25 April 2012 Outline Spin model checker: modeling
More informationHSF-SPIN User Manual
HSF-SPIN User Manual Institut für Informatik Albert-Ludwigs-Universität Georges-Köhler-Allee D-79110 Freiburg email: {edelkamp,lafuente}@informatik.uni-freiburg.de March 22, 2006 Contents 1 Introduction
More informationThe Spin Model Checker : Part I. Moonzoo Kim KAIST
The Spin Model Checker : Part I Moonzoo Kim KAIST Hierarchy of SW Coverage Criteria Complete Value Coverage CVC (SW) Model checking Complete Path Coverage CPC Concolic testing All-DU-Paths Coverage ADUP
More informationDistributed Systems Programming (F21DS1) SPIN: Simple Promela INterpreter
Distributed Systems Programming (F21DS1) SPIN: Simple Promela INterpreter Andrew Ireland Department of Computer Science School of Mathematical and Computer Sciences Heriot-Watt University Edinburgh Overview
More informationFormal Methods for Software Development
Formal Methods for Software Development Verification with Spin Wolfgang Ahrendt 07 September 2018 FMSD: Spin /GU 180907 1 / 34 Spin: Previous Lecture vs. This Lecture Previous lecture Spin appeared as
More informationRoadmap. Tevfik Ko!ar. CSC Operating Systems Fall Lecture - XI Deadlocks - II. Louisiana State University
CSC 4103 - Operating Systems Fall 2009 Lecture - XI Deadlocks - II Tevfik Ko!ar Louisiana State University September 29 th, 2009 1 Roadmap Classic Problems of Synchronization Bounded Buffer Readers-Writers
More informationChapters 5 and 6 Concurrency
Operating Systems: Internals and Design Principles, 6/E William Stallings Chapters 5 and 6 Concurrency Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall Concurrency When several processes/threads
More informationRoadmap. Bounded-Buffer Problem. Classical Problems of Synchronization. Bounded Buffer 1 Semaphore Soln. Bounded Buffer 1 Semaphore Soln. Tevfik Ko!
CSC 4103 - Operating Systems Fall 2009 Lecture - XI Deadlocks - II Roadmap Classic Problems of Synchronization Bounded Buffer Readers-Writers Dining Philosophers Sleeping Barber Deadlock Prevention Tevfik
More informationProcess Synchronization
TDDI04 Concurrent Programming, Operating Systems, and Real-time Operating Systems Process Synchronization [SGG7] Chapter 6 Copyright Notice: The lecture notes are mainly based on Silberschatz s, Galvin
More informationModel Requirements and JAVA Programs MVP 2 1
Model Requirements and JAVA Programs MVP 2 1 Traditional Software The Waterfall Model Problem Area Development Analysis REVIEWS Design Implementation Costly wrt time and money. Errors are found too late
More informationFormal Modeling for Persistence Checking of Signal Transition Graph Specification with Promela
, March 15-17, 2017, Hong Kong Formal Modeling for Persistence Checking of Signal Transition Graph Specification with Promela Kanut Boonroeangkaow, Arthit Thongtak and Wiwat Vatanawood Abstract Signal
More informationPROCESS SYNCHRONIZATION
PROCESS SYNCHRONIZATION Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization Monitors Synchronization
More informationSynchronization Principles
Synchronization Principles Gordon College Stephen Brinton The Problem with Concurrency Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms
More informationFrequently asked questions from the previous class survey
CS 370: OPERATING SYSTEMS [DEADLOCKS] Shrideep Pallickara Computer Science Colorado State University L16.1 Frequently asked questions from the previous class survey Exponential Moving Average Is the α
More informationDeadlock and Monitors. CS439: Principles of Computer Systems September 24, 2018
Deadlock and Monitors CS439: Principles of Computer Systems September 24, 2018 Bringing It All Together Processes Abstraction for protection Define address space Threads Share (and communicate) through
More informationNetwork Protocol Design and Evaluation
Network Protocol Design and Evaluation 05 - Validation, Part I Stefan Rührup Summer 2009 Overview In the last lectures: Specification of protocols and data/message formats In this chapter: Building a validation
More informationCollege of Computer & Information Science Spring 2010 Northeastern University 26 January 2010
College of Computer & Information Science Spring 2010 Northeastern University 26 January 2010 CS 7600: Intensive Computer Systems Scribe: Eric Miles In this lecture, we covered some of the (unwanted) behavior
More informationCSE 153 Design of Operating Systems
CSE 153 Design of Operating Systems Winter 19 Lecture 7/8: Synchronization (1) Administrivia How is Lab going? Be prepared with questions for this weeks Lab My impression from TAs is that you are on track
More informationAlgorithmic Verification. Algorithmic Verification. Model checking. Algorithmic verification. The software crisis (and hardware as well)
Algorithmic Verification The software crisis (and hardware as well) Algorithmic Verification Comp4151 Lecture 1-B Ansgar Fehnker Computer become more powerful (Moore s law) The quality of programs cannot
More informationCS370 Operating Systems
CS370 Operating Systems Colorado State University Yashwant K Malaiya Spring 1018 L11 Synchronization Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ Multilevel feedback queue:
More informationCS477 Formal Software Development Methods / 32
CS477 Formal Software Development Methods 2112 SC, UIUC egunter@illinois.edu http://courses.engr.illinois.edu/cs477 SPIN Beginners Tutorial April 13, 2018 Assertion Violation: mutextwrong1.pml bit flag;
More informationFormal Specification and Verification
Formal Specification and Verification Model Checking with Temporal Logic Bernhard Beckert Based on a lecture by Wolfgang Ahrendt and Reiner Hähnle at Chalmers University, Göteborg Formal Specification
More informationSWEN-220 Mathematical Models of Software. Process Synchronization Critical Section & Semaphores
SWEN-220 Mathematical Models of Software Process Synchronization Critical Section & Semaphores 1 Topics The critical section Synchronization using busy-wait Semaphores 2 The Critical Section Processes
More informationSynchronization. Race Condition. The Critical-Section Problem Solution. The Synchronization Problem. Typical Process P i. Peterson s Solution
Race Condition Synchronization CSCI 315 Operating Systems Design Department of Computer Science A race occurs when the correctness of a program depends on one thread reaching point x in its control flow
More informationModule 6: Process Synchronization. Operating System Concepts with Java 8 th Edition
Module 6: Process Synchronization 6.1 Silberschatz, Galvin and Gagne 2009 Module 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores
More informationSilberschatz and Galvin Chapter 6
Silberschatz and Galvin Chapter 6 Process Synchronization CPSC 410--Richard Furuta 2/26/99 1 Topics discussed Process synchronization Mutual exclusion--hardware Higher-level abstractions Ð Semaphores Ð
More informationProcess Synchronization
Process Synchronization Concurrent access to shared data in the data section of a multi-thread process, in the shared memory of multiple processes, or in a shared file Although every example in this chapter
More informationCS370: System Architecture & Software [Fall 2014] Dept. Of Computer Science, Colorado State University
Frequently asked questions from the previous class survey CS 370: SYSTEM ARCHITECTURE & SOFTWARE [PROCESS SYNCHRONIZATION] Shrideep Pallickara Computer Science Colorado State University Semaphores From
More informationLecture 3 SPIN and Promela
Lecture 3 SPIN and Promela 1 What is SPIN(Simple Promela INterpreter) A tool for analyzing mels of concurrent systems Mels described in Promela Language with concurrent processes Communication via shared
More informationWhat is SPIN(Simple Promela Interpreter) Elements of Promela. Material About SPIN. Basic Variables and Types. Typical Structure of Promela Model
What is SPIN(Simple Promela Interpreter) Lecture XX SPIN and Promela A tool for analyzing mels of reactive systems Mels described in Promela Language with concurrent processes, Communication via channels,
More informationSemaphore. Originally called P() and V() wait (S) { while S <= 0 ; // no-op S--; } signal (S) { S++; }
Semaphore Semaphore S integer variable Two standard operations modify S: wait() and signal() Originally called P() and V() Can only be accessed via two indivisible (atomic) operations wait (S) { while
More informationPromela and SPIN. Mads Dam Dept. Microelectronics and Information Technology Royal Institute of Technology, KTH. Promela and SPIN
Promela and SPIN Mads Dam Dept. Microelectronics and Information Technology Royal Institute of Technology, KTH Promela and SPIN Promela (Protocol Meta Language): Language for modelling discrete, event-driven
More informationLesson 6: Process Synchronization
Lesson 6: Process Synchronization Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks Semaphores Classic Problems of Synchronization
More informationChapter 6: Process Synchronization. Module 6: Process Synchronization
Chapter 6: Process Synchronization Module 6: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Semaphores Classic Problems of Synchronization
More informationCSE 4/521 Introduction to Operating Systems
CSE 4/521 Introduction to Operating Systems Lecture 7 Process Synchronization II (Classic Problems of Synchronization, Synchronization Examples) Summer 2018 Overview Objective: 1. To examine several classical
More informationChapter 5: Process Synchronization. Operating System Concepts 9 th Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationA Practical approach on Model checking with Modex and Spin
International Journal of Electrical & Computer Sciences IJECS-IJENS Vol: 11 No: 05 1 A Practical approach on Model checking with Modex and Spin Muhammad Iqbal Hossain #1, Nahida Sultana Chowdhury *2 #
More informationConcurrency. Chapter 5
Concurrency 1 Chapter 5 2 Concurrency Is a fundamental concept in operating system design Processes execute interleaved in time on a single processor Creates the illusion of simultaneous execution Benefits
More informationRecall from Chapter 1 that a data race is a failure to correctly implement critical sections for non-atomic shared variable accesses.
3.10 Tracing, Testing, and Replay for Semaphores and Locks Outline: A technique for detecting violations of mutual exclusion. Tracing and replaying executions during debugging. Deadlock detection Reachability
More informationMidterm Exam #2 Solutions October 25, 2016 CS162 Operating Systems
University of California, Berkeley College of Engineering Computer Science Division EECS all 2016 Anthony D. Joseph Midterm Exam #2 Solutions October 25, 2016 CS162 Operating Systems Your Name: SID AND
More informationChapter 6: Process Synchronization
Chapter 6: Process Synchronization Objectives Introduce Concept of Critical-Section Problem Hardware and Software Solutions of Critical-Section Problem Concept of Atomic Transaction Operating Systems CS
More informationTesting Concurrent Programs: Model Checking SPIN. Bengt Jonsson
Testing Concurrent Programs: Model Checking SPIN Bengt Jonsson Model Checking Section Weeks 15 and 16. Goal: Understand and use the basics of Model checking, using state space exploration Modeling parallel
More informationProgramming Languages
Programming Languages Tevfik Koşar Lecture - XXVI April 27 th, 2006 1 Roadmap Shared Memory Synchronization Spin Locks Barriers Semaphores Monitors 2 1 Memory Architectures Distributed Memory Shared Memory
More informationOperating Systems: William Stallings. Starvation. Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall
Operating Systems: Internals and Design Principles, 6/E William Stallings Chapter 6 Concurrency: Deadlock and Starvation Patricia Roy Manatee Community College, Venice, FL 2008, Prentice Hall Deadlock
More informationWhat is SPIN(Simple Promela Interpreter) Material About SPIN. Elements of Promela. Basic Variables and Types. Typical Structure of Promela Model
What is SPIN(Simple Promela Interpreter) Lecture 3 SPIN and Promela A tool for analyzing mels of reactive systems Mels described in Promela Language with concurrent processes, Communication via channels,
More informationProcess Management And Synchronization
Process Management And Synchronization In a single processor multiprogramming system the processor switches between the various jobs until to finish the execution of all jobs. These jobs will share the
More informationProcess Synchronization
CS307 Process Synchronization Fan Wu Department of Computer Science and Engineering Shanghai Jiao Tong University Spring 2018 Background Concurrent access to shared data may result in data inconsistency
More informationProcess Synchronization
Process Synchronization Chapter 6 2015 Prof. Amr El-Kadi Background Concurrent access to shared data may result in data inconsistency Maintaining data consistency requires mechanisms to ensure the orderly
More informationConcurrency: Principles of Deadlock. Processes and resources. Concurrency and deadlocks. Operating Systems Fall Processes need resources to run
Concurrency: Principles of Deadlock Operating Systems Fall 2002 Processes and resources Processes need resources to run CPU, memory, disk, etc process waiting for a resource cannot complete its execution
More informationCHAPTER 6: PROCESS SYNCHRONIZATION
CHAPTER 6: PROCESS SYNCHRONIZATION The slides do not contain all the information and cannot be treated as a study material for Operating System. Please refer the text book for exams. TOPICS Background
More informationCS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring Lecture 8: Semaphores, Monitors, & Condition Variables
CS 162 Operating Systems and Systems Programming Professor: Anthony D. Joseph Spring 2004 Lecture 8: Semaphores, Monitors, & Condition Variables 8.0 Main Points: Definition of semaphores Example of use
More informationCS370 Operating Systems
CS370 Operating Systems Colorado State University Yashwant K Malaiya Fall 2017 Lecture 12 Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ 2 Mutex vs Semaphore Mutex is binary,
More informationDeadlock and Monitors. CS439: Principles of Computer Systems February 7, 2018
Deadlock and Monitors CS439: Principles of Computer Systems February 7, 2018 Last Time Terminology Safety and liveness Atomic Instructions, Synchronization, Mutual Exclusion, Critical Sections Synchronization
More informationTHREADS & CONCURRENCY
27/04/2018 Sorry for the delay in getting slides for today 2 Another reason for the delay: Yesterday: 63 posts on the course Piazza yesterday. A7: If you received 100 for correctness (perhaps minus a late
More informationThread Synchronization: Too Much Milk
Thread Synchronization: Too Much Milk 1 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing mutual exclusion with memory reads and writes
More informationIntroduction to programming with semaphores Fri 1 Sep 2017
Introduction to programming with semaphores Fri 1 Sep 2017 K. V. S. Prasad Dept of Computer Science Chalmers University Lecture 2 of TDA384/DIT301, August October2017 Assignments? How s it going with the
More informationMore on Synchronization and Deadlock
Examples of OS Kernel Synchronization More on Synchronization and Deadlock Two processes making system calls to read/write on the same file, leading to possible race condition on the file system data structures
More information1. Motivation (Race Condition)
COSC4740-01 Operating Systems Design, Fall 2004, Byunggu Yu Chapter 6 Process Synchronization (textbook chapter 7) Concurrent access to shared data in the data section of a multi-thread process, in the
More informationRoadmap. Tevfik Koşar. CSE 421/521 - Operating Systems Fall Lecture - X Deadlocks - I. University at Buffalo. Synchronization structures
CSE 421/521 - Operating Systems Fall 2012 Lecture - X Deadlocks - I Tevfik Koşar University at Buffalo October 2nd, 2012 1 Roadmap Synchronization structures Problems with Semaphores Monitors Condition
More informationRoadmap. Problems with Semaphores. Semaphores. Monitors. Monitor - Example. Tevfik Koşar. CSE 421/521 - Operating Systems Fall 2012
CSE 421/521 - Operating Systems Fall 2012 Lecture - X Deadlocks - I Tevfik Koşar Synchronization structures Problems with Semaphores Monitors Condition Variables Roadmap The Deadlock Problem Characterization
More informationDeadlocks. Copyright : University of Illinois CS 241 Staff 1
Deadlocks 1 Deadlock Which way should I go? 2 Deadlock I Oh can no! almost I m get stuck! across GRIDLOCK! 3 Deadlock Definition Deadlocked process Waiting for an event that will never occur Typically,
More informationChapter 6: Process Synchronization
Chapter 6: Process Synchronization Chapter 6: Synchronization 6.1 Background 6.2 The Critical-Section Problem 6.3 Peterson s Solution 6.4 Synchronization Hardware 6.5 Mutex Locks 6.6 Semaphores 6.7 Classic
More informationEMBEDDED C CODE 17. SPIN Version 4 supports the inclusion of embedded C code into PROMELA models through the following fiv e new primitives:
EMBEDDED C CODE 17 The purpose of analysis is not to compel belief but rather to suggest doubt. (Imre Lakatos, Proofs and Refutations) SPIN Version 4 supports the inclusion of embedded C code into PROMELA
More informationThe Dining Philosophers with Pthreads
The Dining Philosophers with Pthreads Dr. Douglas Niehaus Michael Jantz Dr. Prasad Kulkarni EECS 678 Dining Philosophers 1 Introduction The Dining Philosophers canonical problem illustrates a number of
More informationSafety and liveness for critical sections
Safety and liveness for critical sections! At most k threads are concurrently in the critical section A. Safety B. Liveness C. Both! A thread that wants to enter the critical section will eventually succeed
More informationDining Philosophers, Semaphores
CS 220: Introduction to Parallel Computing Dining Philosophers, Semaphores Lecture 27 Today s Schedule Dining Philosophers Semaphores Barriers Thread Safety 4/30/18 CS 220: Parallel Computing 2 Today s
More informationSemaphores. A semaphore is an object that consists of a. methods (e.g., functions): signal and wait. semaphore. method signal. counter.
Semaphores 1 Semaphores A semaphore is an object that consists of a counter, a waiting list of processes, and two methods (e.g., functions): signal and wait. method signal method wait counter waiting list
More informationConcurrency: Deadlock and Starvation. Chapter 6
Concurrency: Deadlock and Starvation Chapter 6 Deadlock Permanent blocking of a set of processes that either compete for system resources or communicate with each other Involve conflicting needs for resources
More informationMulti-Threaded System int x, y, r; int *p, *q, *z; int **a; EEC 421/521: Software Engineering. Thread Interleaving SPIN. Model Checking using SPIN
EEC 421/521: Software Engineering Model Checking using SPIN 4/29/08 EEC 421/521: Software Engineering 1 Multi-Threaded System int x, y, r; int *p, *q, *z; int **a; thread_1(void) /* initialize p, q, and
More informationChapter 5: Process Synchronization
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Operating System Concepts 9th Edition Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution
More informationChapter 5: Process Synchronization. Operating System Concepts 9 th Edition
Chapter 5: Process Synchronization Silberschatz, Galvin and Gagne 2013 Chapter 5: Process Synchronization Background The Critical-Section Problem Peterson s Solution Synchronization Hardware Mutex Locks
More informationCS370 Operating Systems
CS370 Operating Systems Colorado State University Yashwant K Malaiya Fall 2017 Lecture 11 Slides based on Text by Silberschatz, Galvin, Gagne Various sources 1 1 FAQ Multilevel Feedback Queue: Q0, Q1,
More informationCS477 Formal Software Development Methods / 39
CS477 Formal Software Development Methods 2112 SC, UIUC egunter@illinois.edu http://courses.engr.illinois.edu/cs477 SPIN Beginners Tutorial April 11, 2018 Hello World /* A "Hello World" Promela model for
More informationResource Allocation. Pradipta De
Resource Allocation Pradipta De pradipta.de@sunykorea.ac.kr Outline Dining Philosophers Problem Drinking Philosophers Problem Dining Philosophers Problem f(5) 5 f(1) Each philosopher goes through, Think
More informationAutomated Reasoning. Model Checking with SPIN (II)
Automated Reasoning Model Checking with SPIN (II) Alan Bundy page 1 Verifying Global Properties Assertions can be used to verify a property locally For example, place assert(memreturned) at the end of
More informationSystem Correctness. EEC 421/521: Software Engineering. System Correctness. The Problem at Hand. A system is correct when it meets its requirements
System Correctness EEC 421/521: Software Engineering A Whirlwind Intro to Software Model Checking A system is correct when it meets its requirements a design without requirements cannot be right or wrong,
More information