Concurrency. A process is a program executing on a virtual computer Processor speed and multiplexing of shared resources are ignored Order of thread execution.

Slides:



Advertisements
Similar presentations
CS 267: Automated Verification Lecture 8: Automata Theoretic Model Checking Instructor: Tevfik Bultan.
Advertisements

CS 290C: Formal Models for Web Software Lecture 3: Verification of Navigation Models with the Spin Model Checker Instructor: Tevfik Bultan.
Automatic Verification Book: Chapter 6. What is verification? Traditionally, verification means proof of correctness automatic: model checking deductive:
Program correctness The State-transition model A global state S  s 0 x s 1 x … x s m {s k = local state of process k} S0  S1  S2  … Each state transition.
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Process Synchronization Continued 7.2 The Critical-Section Problem.
1 Chapter 2 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld © 2007 Synchronization Algorithms and Concurrent Programming Gadi Taubenfeld.
Chapter 6: Process Synchronization
Background Concurrent access to shared data can lead to inconsistencies Maintaining data consistency among cooperating processes is critical What is wrong.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
5.1 Silberschatz, Galvin and Gagne ©2009 Operating System Concepts with Java – 8 th Edition Chapter 5: CPU Scheduling.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
Multiprocessor Synchronization Algorithms ( ) Lecturer: Danny Hendler The Mutual Exclusion problem.
Process Synchronization. Module 6: Process Synchronization Background The Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores.
1 Operating Systems, 122 Practical Session 5, Synchronization 1.
CH7 discussion-review Mahmoud Alhabbash. Q1 What is a Race Condition? How could we prevent that? – Race condition is the situation where several processes.
תרגול 9 META LABELS. Basic types of claims State properties.
PSWLAB S PIN Search Algorithm from “THE SPIN MODEL CHECKER” by G Holzmann Presented by Hong,Shin 9 th Nov SPIN Search Algorithm.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 12 The Critical Section problem John Gurd, Graham Riley Centre for Novel.
Chapter 3 The Critical Section Problem
The Spin Model Checker Promela Introduction Nguyen Tuan Duc Shogo Sawai.
Spin Tutorial (some verification options). Assertion is always executable and has no other effect on the state of the system than to change the local.
Concurrency.
© 2011 Carnegie Mellon University SPIN: Part Bug Catching: Automated Program Verification and Testing Sagar Chaki November 2, 2011.
The Critical-Section Problem
Chapter 6: Process Synchronization. Outline Background Critical-Section Problem Peterson’s Solution Synchronization Hardware Semaphores Classic Problems.
University of Pennsylvania 9/19/00CSE 3801 Concurrent Processes CSE 380 Lecture Note 4 Insup Lee.
Chapter 6: Synchronization. 6.2 Silberschatz, Galvin and Gagne ©2005 Operating System Principles Module 6: Synchronization 6.1 Background 6.2 The Critical-Section.
CS 290C: Formal Models for Web Software Lecture 4: Model Checking Navigation Models with Spin Instructor: Tevfik Bultan.
Instructor: Umar KalimNUST Institute of Information Technology Operating Systems Process Synchronization.
Adopted from and based on Textbook: Operating System Concepts – 8th Edition, by Silberschatz, Galvin and Gagne Updated and Modified by Dr. Abdullah Basuhail,
1 Race Conditions/Mutual Exclusion Segment of code of a process where a shared resource is accessed (changing global variables, writing files etc) is called.
Operating Systems CSE 411 CPU Management Oct Lecture 13 Instructor: Bhuvan Urgaonkar.
1 Thread Synchronization: Too Much Milk. 2 Implementing Critical Sections in Software Hard The following example will demonstrate the difficulty of providing.
Wishnu Prasetya Model Checking with SPIN A Bit More about SPIN.
The Critical Section Problem
Correctness requirements. Basic Types of Claims Basic assertions End-state labels Progress-state labels Accept-state labels Never claims Trace assertions.
Process Synchronization Continued 7.2 Critical-Section Problem 7.3 Synchronization Hardware 7.4 Semaphores.
Sept COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 15 More Advanced Program Properties: Temporal logic and jSpin John Gurd,
MODEL CHECKING WITH SPIN MODELING AND VERIFICATION WITH SPIN ANDREA ORLANDINI – ISTC (CNR) TexPoint fonts used in EMF. Read the TexPoint manual before.
Today’s Agenda  Quiz 4 next Tuesday  Quick Review  Continue on SPIN Overview.
1 Chapter 2.3 : Interprocess Communication Process concept  Process concept  Process scheduling  Process scheduling  Interprocess communication Interprocess.
Program correctness The State-transition model A global states S  s 0 x s 1 x … x s m {s k = set of local states of process k} S0  S1  S2  Each state.
Hwajung Lee. The State-transition model The set of global states = s 0 x s 1 x … x s m {s k is the set of local states of process k} S0  S1  S2  Each.
1 Concurrent Processes. 2 Cooperating Processes  Operating systems allow for the creation and concurrent execution of multiple processes  concurrency.
The Spin Model Checker : Part I Moonzoo Kim KAIST.
CIS 842: Specification and Verification of Reactive Systems Lecture INTRO-Examples: Simple BIR-Lite Examples Copyright 2004, Matt Dwyer, John Hatcliff,
Hwajung Lee. The State-transition model The set of global states = s 0 x s 1 x … x s m {s k is the set of local states of process k} S0  S1  S2  Each.
Computer Architecture and Operating Systems CS 3230: Operating System Section Lecture OS-5 Process Synchronization Department of Computer Science and Software.
Synchronicity Introduction to Operating Systems: Module 5.
/ PSWLAB S PIN Search Optimization from “THE SPIN MODEL CHECKER” by G. Holzmann Presented by Hong,Shin 23 th Nov SPIN Search.
Lecture 4 Introduction to Promela. Promela and Spin Promela - process meta language G. Holzmann, Bell Labs (Lucent) C-like language + concurrency dyamic.
Silberschatz, Galvin and Gagne ©2009 Operating System Concepts – 8 th Edition, Chapter 6: Process Synchronization.
CGS 3763 Operating Systems Concepts Spring 2013 Dan C. Marinescu Office: HEC 304 Office hours: M-Wd 11: :30 AM.
Program Correctness. The designer of a distributed system has the responsibility of certifying the correctness of the system before users start using.
Software Systems Verification and Validation Laboratory Assignment 4 Model checking Assignment date: Lab 4 Delivery date: Lab 4, 5.
CS4315A. Berrached:CMS:UHD1 Process Synchronization Chapter 8.
Synchronization Questions answered in this lecture: Why is synchronization necessary? What are race conditions, critical sections, and atomic operations?
Chapter 6 Synchronization Dr. Yingwu Zhu. The Problem with Concurrent Execution Concurrent processes (& threads) often access shared data and resources.
Chapter 5: Process Synchronization
ITEC452 Distributed Computing Lecture 5 Program Correctness
The Critical-Section Problem
Grades.
Concurrency: Mutual Exclusion and Process Synchronization
Chapter 6: Process Synchronization
Chapter 6: Synchronization Tools
COMP60621 Designing for Parallelism
CIS 720 Lecture 5.
CSE 542: Operating Systems
Don Porter Portions courtesy Emmett Witchel
Presentation transcript:

Concurrency

A process is a program executing on a virtual computer Processor speed and multiplexing of shared resources are ignored Order of thread execution is non-deterministic –Multiprocessing A system may contain multiple processors on which cooperating threads/processes can execute simultaneously –Multi-programming Thread/process execution can be interleaved on a single processor because of time-slicing

The Basic Issue Operations are not atomic An atomic operation is one that executes to completion or does not execute at all An atomic operation has “an all or nothing” flavor: –Either it executes to completion, or –Does not execute at all, and –No one can see a partially-executed state

Critical Sections A critical section is: –Consecutive program instructions –all instruction executes atomically A critical section implementation must allow only one thread to execute in the critical section at any given time A good implementation –Allows maximum concurrency while preserving correctness

Implementation Permit access to shared variables only within a critical section General program structure Entry section Wait if already locked “Lock” Critical section code Exit critical section “Unlock”

Properties Concurrent programs are specified using properties, which is a predicate that evaluated over a run of the concurrent program. –Thus, it has the value true or false in each run of the program. –We say that the property holds if it is true in each run. A property: the value of x is always at least as large as the value of y, and x has the value of 0 at least once. Not a property: the average number of processes waiting on a lock is less than 1.

Safety and liveness Any property is either –a safety property, –A liveness property, or –a conjunction of a safety and a liveness property.

Safety A safety property is of the form nothing bad happens (i.e., all states are safe). Examples: –The number of processes in a critical section is always less than 2. –Let p be the sequence of produced values and c be the sequence of consumed values. c is always a prefix of p.

Liveness A liveness property is of the form something good happens (i.e., a state is eventually achieved). Examples: –A process that wishes to enter the critical section eventually enters. –p grows without bound. For every value x in p, x is eventually in c.

Safety and Liveness Showing a safety property P holds: –find a safety property P’: P’ => P; –show that P’ initially holds; –show that each step of the program maintains P’. Showing a liveness property holds is usually done by induction.

Basic Properties Finite progress axiom Each process takes a step infinitely often. Atomic shared variables Consider {x = A} any concurrent read of x will return x = B; either A or B. {x = B} {x = 0} cobegin x = x + 1; || x = x - 1; coend {x ∈ {-1, 0 1} }

Producer/Consumer Let p be the sequence of produced values and c be the sequence of consumed values. c is always a prefix of p. For every value x in p, x is eventually in c. –Bounded buffer variant: Always |p| − |c| ≤ max

Producer Active proctype producer () { do :: (turn== P) -> printf(“Produce\n”) turn = C od }

Consumer Active proctype consumer() { do :: (turn== C) -> printf(“\tConsumer\n”) turn = P od }

Correctness Conditions A correct solution to the critical section problem must satisfy: –Safety: Nothing bad ever happens! At most one thread may be executing in the critical section (mutual exclusion) –Liveness: Eventually something good happens!! If one of more threads are in their entry section, then eventually at least one of them enters the critical section. Further requirement: –Bounded waiting: If a thread iis in entry section, then there is a bound on the number of times that other threads are allowed to enter the critical section before thread i’ s request is granted

Step by Step Initial value of turn is p At least one producer will find the guard :: (turn== P) -> to be true So, using UNIX: Spin prodcons.pml | more Produce Consume Produce Consume Not using UNIX: Spin –u14 prodcons.pml Produce Consume Produce Consume Depth-limit (-u14 steps) reached

Extensing the Example Instantiate more than 1 process Active [2] proctype producer() {…} Now we may violate CS by have 2 procucers in the CS [ ::(turn== P) ->]

Revised Producer Consumer Example mtype = { P,C,N}; mtype turn=P; pid who; inline request(x,y) { atomic(x=y; who=0} } Inline release(x,y) { atomic {x=y; who=0} }

Main Code Active [2] proctype producer() { do :: request (turn, P, N) -> printf (“P%d\n”,_pid); assert (who== _pid); release (turn, C) od } Active [2] proctype consumer() { do :: request (turn, C, N) -> printf (“C%d\n”,_pid); assert (who== _pid); release (turn, P) od }

Printout Spin prodcons2.pml P1 C2 P1 C3 P0 C3 P1C3 … There is some non determinism in the model, since both consumers share the same guard condition

Further Simulation init{ assert (false) } spin false.pml spin: line 1 “false.pml“, Error: assertion violated A simulation is not a proof! To prove that, invoke SPIN in verification mode spin –a prodcons2.pml #generate a verifier cc –o pan pan.c #compile the verifier

./pan#perform the verification (Spin version August 2003) Full statespace search for: never claim- (none specified) assertion violations + acceptance cycles- (not selected) invalid end state+ State-vector 28 bytes, depth reached 7, errors: 0 14states, stored 3states, matched 17transitions (= stored + matched) 0atomic steps

Summary State-space = very small No errors No assertion violations

Dekker's mutex algorithm bool turn, flag[2]; byte cnt; active [2] proctype mutex() /* Dekker's 1965 algorithm */ { pid i, j; i = _pid; j = 1 - _pid; again: flag[i] = true; do :: flag[j] -> if :: turn == j -> flag[i] = false; !(turn == j); flag[i] = true :: else fi :: else -> break od; cnt++; assert(cnt == 1); cnt--; /* critical section */ turn = j; flag[i] = false; Goto again }

Spin Verification spin -a mutex.pml cc -o pan pan.c./pan (Spin Version – 1 August 2003) + Partial Order Reduction Full statespace search for: never claim - (none specified) assertion violations + cycle checks - (disabled by - DSAFETY) invalid end states + State-vector 20 byte, depth reached 65, errors: states, stored 173 states, matched 363 transitions (= stored+matched) 0 atomic steps hash conflicts: 0 (resolved) (max size 2^18 states)

Faulty Mutual Exclusion Algorithm Byte cnt; Byte x,y,z; Active[2] proctype user() {byte me= -pid+1; Again: x=me; if :: (y==0)||y==me)->skip :: else->goto again fi;

z=me; if :: (x==me)->skip :: else->goto again fi; y=me; if :: (z==me)->skip :: else->goto again fi; /* enter CS */ cnt++; assert(cnt==1); cnt--; goto again; }

Spin’s Verdict spin – a mutex_flaw.pml cc -0 pan pan.c.pan pan: assertion violated (cnt==1) (at depth 53) pan: wrote mutex_flaw.pml.trail

Bakery Algorithm proctype A() { do :: 1 -> turnA = 1; turnA = turnB + 1; (turnB == 0) || (turnA < turnB); mutex ++; mutex --; turnA = 0; od }

Dekker’s solution to the two process mutual exclusion problem #define true 1 #define false 0 #define Aturn false #define Bturn true bool x, y, t; proctype A() { x = true; t = Bturn; (y == false||t == Aturn); /*critical section*/ x = false } proctype B() { y = true; t = Aturn; (x == false || t == Bturn); /* critical section */ y = false } init { run A(); run B() }

Peterson's Mutual Exclusion bit active [2] ; bit last ; byte crit ; proctype threadMX (bit self) { do :: break :: active [self] = 1 ; last = self ; (last != self || ! active[1-self]) ; /* insufficient is: (last != self) ; */ crit ++ ; assert crit == 1 ; /* mutual exclusion */ crit -- ; active [self] = 0 ; od } init { run threadMX (0) ; run threadMX (1) ; }

Message Passing Mtype = {ini, ack, dreg, data, shutup, quiet, dead}; Chan M = [1] of {mtype}: Chan W = [1] of {mtype};

Active proctype Mproc() { W!ini;/*connection*/ M?ack;/*handshake*/ timeout->/*wait*/ if/*two options*/ :: W!shutup/*start shutdown */ :: W!dreq/*or request data */ M?data/*receive data*/ do :: W!data/*send data*/ :: W!shutup;/*or shutdown*/ break; od fi; M?shutup;/*shutdown handshake */ W!quiet; M?dead }

Active proctype Wproc() { W?ini;/*wait for ini*/ M!ack;/*acknowledge*/ do/*3 options*/ :: W?dreq->/*data requested*/ M!data/*send data */ :: W?data->/*receive data*/ skip/*no response*/ :: W?shutup -> M!shutup;/*start shutdown*/ break; od; W?quiet; M!dead }

Spin –c protocol Proc 0 = Mproc Proc 1 = Wproc q\p W!ini 1 -W?ini 2 -M!ack 2 M?ack Timeout 1 W!shutup 1 - W?shutup 2 -M! shutup 2 M?shutup 1 W!quiet 1 - W?quiet 2 - M!dead 2 M?dead …

SPIN Output proctype A state 1 -> state 2 => x = 1 state 2 -> state 3 => t = 1 state 3 -> state 4 => ((y == 0) || (t == 0)) state 4 -> state 5 => x = 0 state 5 -> state 0 => -end proctype B state 1 -> state 2 => y = 1 state 2 -> state 3 => t = 0 state 3 -> state 4 => ((x == 0) || (t == 1)) state 4 -> state 5 => y = 0 state 5 -> state 0 => -end proctype init state 1 -> state 2 => (run A()) state 2 -> state 3 => (run B()) state 3 -> state 0 => -end-

Reader-Writer #define invariant (nr == 0 || !busy) byte nr; bool busy; proctype reader(){ do :: atomic{ (!busy) -> nr=nr+1} /* reading */ nr=nr-1 od; } proctype writer (){ do ::atomic { (nr==0 && !busy) ->busy=1} /*writing*/ busy=0; od;

Reader/Writer #define invariant (nr == 0 || !busy) byte nr; bool busy; proctype reader(){ do :: atomic{ (!busy) -> nr=nr+1} /* reading */ nr=nr-1 od; } proctype writer (){ do ::atomic { (nr==0 && !busy) ->busy=1} /*writing*/ busy=0; od; init{ nr=0; busy=0; run reader(); run writer(); } if :: (! ((invariant))) -> goto accept_all :: (1) -> goto T0_init fi; accept_all: skip }