3. Safety and Synchronization Prof. O. Nierstrasz Selected material © Magee and Kramer.

Slides:



Advertisements
Similar presentations
Operating Systems Semaphores II
Advertisements

Operating Systems: Monitors 1 Monitors (C.A.R. Hoare) higher level construct than semaphores a package of grouped procedures, variables and data i.e. object.
50.003: Elements of Software Construction Week 6 Thread Safety and Synchronization.
Practice Session 7 Synchronization Liveness Deadlock Starvation Livelock Guarded Methods Model Thread Timing Busy Wait Sleep and Check Wait and Notify.
Ch 7 B.
Concurrency Important and difficult (Ada slides copied from Ed Schonberg)
Ch. 7 Process Synchronization (1/2) I Background F Producer - Consumer process :  Compiler, Assembler, Loader, · · · · · · F Bounded buffer.
Silberschatz, Galvin and Gagne ©2007 Operating System Concepts with Java – 7 th Edition, Nov 15, 2006 Chapter 6 (a): Synchronization.
Chapter 6 Process Synchronization Bernard Chen Spring 2007.
Chapter 6: 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.
12. Common Errors, a few Puzzles. © O. Nierstrasz P2 — Common Errors, a few Puzzles 12.2 Common Errors, a few Puzzles Sources  Cay Horstmann, Computing.
5. Liveness and Guarded Methods Prof. O. Nierstrasz Selected material © Magee and Kramer.
ESE Einführung in Software Engineering 7. Modeling Behaviour Prof. O. Nierstrasz.
Introduction to Software Engineering 7. Modeling Behaviour.
CS 5704 Fall 00 1 Monitors in Java Model and Examples.
Concurrency: safety & liveness properties1 ©Magee/Kramer 2 nd Edition COMP60611 Fundamentals of Parallel and Distributed Systems Lecture 14 Safety and.
Liang, Introduction to Java Programming, Seventh Edition, (c) 2009 Pearson Education, Inc. All rights reserved Chapter 5 Multithreading and.
8. Condition Objects Prof. O. Nierstrasz Selected material © 2005 Bowbeer, Goetz, Holmes, Lea and Peierls.
CP — Concurrent Programming 5. Safety and Liveness Properties Prof. O. Nierstrasz Wintersemester 2005 / 2006.
CP — Concurrent Programming 8. Liveness and Asynchrony Prof. O. Nierstrasz Wintersemester 2005 / 2006.
2. Java and Concurrency Prof. O. Nierstrasz Selected material © Magee and Kramer.
10. Petri Nets Prof. O. Nierstrasz. Roadmap  Definition: —places, transitions, inputs, outputs —firing enabled transitions  Modelling: —concurrency.
12. Summary, Trends, Research. © O. Nierstrasz PS — Summary, Trends, Research Roadmap  Summary: —Trends in programming paradigms  Research:...
ESE Einführung in Software Engineering N. XXX Prof. O. Nierstrasz Fall Semester 2009.
Avishai Wool lecture Introduction to Systems Programming Lecture 4 Inter-Process / Inter-Thread Communication.
CP — Concurrent Programming 2. Java and Concurrency Prof. O. Nierstrasz Wintersemester 2005 / 2006.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
CP — Concurrent Programming 12. Petri Nets Prof. O. Nierstrasz Wintersemester 2005 / 2006.
Metamodeling Seminar X. CHAPTER Prof. O. Nierstrasz Spring Semester 2008.
ESE Einführung in Software Engineering X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
N. XXX Prof. O. Nierstrasz Thanks to Jens Palsberg and Tony Hosking for their kind permission to reuse and adapt the CS132 and CS502 lecture notes.
Synchronization in Java Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
7. Fixed Points. © O. Nierstrasz PS — Fixed Points 7.2 Roadmap  Representing Numbers  Recursion and the Fixed-Point Combinator  The typed lambda calculus.
CP — Concurrent Programming 3. Safety and Synchronization Prof. O. Nierstrasz Wintersemester 2005 / 2006.
7. Liveness and Asynchrony Prof. O. Nierstrasz. Roadmap  Asynchronous invocations  Simple Relays —Direct invocations —Thread-based messages —Command-based.
3. Safety and Synchronization Prof. O. Nierstrasz Selected material © Magee and Kramer.
A. Frank - P. Weisberg Operating Systems Introduction to Cooperating Processes.
OORPT Object-Oriented Reengineering Patterns and Techniques X. CHAPTER Prof. O. Nierstrasz.
CP — Concurrent Programming X. CHAPTER Prof. O. Nierstrasz Wintersemester 2005 / 2006.
Concurrency - 1 Tasking Concurrent Programming Declaration, creation, activation, termination Synchronization and communication Time and delays conditional.
12. eToys. © O. Nierstrasz PS — eToys 12.2 Denotational Semantics Overview:  … References:  …
Concurrency Recitation – 2/24 Nisarg Raval Slides by Prof. Landon Cox.
Parallel Processing (CS526) Spring 2012(Week 8).  Thread Status.  Synchronization in Shared Memory Programming(Java threads ) ◦ Locks ◦ Barriars.
Object Oriented Programming Lecture 8: Introduction to laboratorial exercise – part II, Introduction to GUI frames in Netbeans, Introduction to threads.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
Critical Problem Revisit. Critical Sections Mutual exclusion Only one process can be in the critical section at a time Without mutual exclusion, results.
Semaphores, Locks and Monitors By Samah Ibrahim And Dena Missak.
Internet Software Development Controlling Threads Paul J Krause.
CSC321 Concurrent Programming: §5 Monitors 1 Section 5 Monitors.
Concurrency: Mutual Exclusion and Synchronization Chapter 5.
1 Concurrency: Mutual Exclusion and Synchronization Chapter 5.
ICS 313: Programming Language Theory Chapter 13: Concurrency.
Threads Doing Several Things at Once. Threads n What are Threads? n Two Ways to Obtain a New Thread n The Lifecycle of a Thread n Four Kinds of Thread.
CS399 New Beginnings Jonathan Walpole. 2 Concurrent Programming & Synchronization Primitives.
1 Condition Variables CS 241 Prof. Brighten Godfrey March 16, 2012 University of Illinois.
U NIVERSITY OF M ASSACHUSETTS A MHERST Department of Computer Science Computer Systems Principles Synchronization Emery Berger and Mark Corner University.
CP — Concurrent Programming 6. Liveness and Guarded Methods Prof. O. Nierstrasz Wintersemester 2005 / 2006.
Comunication&Synchronization threads 1 Programación Concurrente Benemérita Universidad Autónoma de Puebla Facultad de Ciencias de la Computación Comunicación.
CS 153 Design of Operating Systems Winter 2016 Lecture 7: Synchronization.
The Relative Power of Synchronization Operations Companion slides for The Art of Multiprocessor Programming by Maurice Herlihy & Nir Shavit.
CSC321 §8 Implementing FSP Models in Java 1 Section 8 Implementing FSP Models in Java.
Multithreading / Concurrency
Background on the need for Synchronization
Critical section problem
CSE 153 Design of Operating Systems Winter 19
CS333 Intro to Operating Systems
Software Engineering and Architecture
Java Chapter 3 (Estifanos Tilahun Mihret--Tech with Estif)
Presentation transcript:

3. Safety and Synchronization Prof. O. Nierstrasz Selected material © Magee and Kramer

© Oscar Nierstrasz 2 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

© Oscar Nierstrasz 3 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

© Oscar Nierstrasz Safety and Synchronization 4 Modelling interaction — shared actions Actions that are common between two processes are shared and can be used to model process interaction:  Unshared actions may be arbitrarily interleaved  Shared actions occur simultaneously for all participants What are the states of the LTS? The traces? MAKER= ( make -> ready -> MAKER ). USER= ( ready -> use -> USER ). ||MAKER_USER = ( MAKER || USER ). 01

© Oscar Nierstrasz Safety and Synchronization 5 Modelling interaction — handshake A handshake is an action that signals acknowledgement What are the states and traces of the LTS? 01 MAKERv2= ( make -> ready -> used -> MAKERv2 ). USERv2= ( ready -> use -> used -> USERv2 ). ||MAKER_USERv2 = ( MAKERv2 || USERv2 ).

© Oscar Nierstrasz 6 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

© Oscar Nierstrasz Safety and Synchronization 7 Safety problems Objects must only be accessed when they are in a consistent state, formalized by a class invariant. Each method assumes the class invariant holds when it starts, and it re-establishes it when done. If methods interleave arbitrarily, an inconsistent state may be accessed, and the object may be left in a “dirty” state. Where shared resources are updated may be a critical section. m1 m2 m3 m4 m5 Consistent states ?!

Race conditions © Oscar Nierstrasz Safety and Synchronization 8 A race condition exists if safety may be violated by bad timing public class AccountBAD extends Account { // unsynchronized! public void withdraw(int amount) { while (amount > assets) { Thread.yield();// busy wait } Thread.yield();// race condition! assets -= amount; checkInvariant();// might fail! } if (!(assets >= 0)) { errors++; } Account

© Oscar Nierstrasz Safety and Synchronization 9 Interference Consider the two processes: How can these processes interfere? { x = 0 } AInc:x := x+1 BInc:x := x+1 { x = ? }

© Oscar Nierstrasz Safety and Synchronization 10 Atomic actions Individual reads and writes may be atomic actions: const N=3 range T=0..N Var=Var[0], Var[u:T]=( read[u]-> Var[u] | write[v:T] -> Var[v] ). set VarAlpha = { read[T], write[T] } Inc =(read[v:0..N-1] ->write[v+1] ->STOP )+VarAlpha.

© Oscar Nierstrasz Safety and Synchronization 11 Sequential behaviour A single sequential thread requires no synchronization: ||SeqInc = (Var||Inc). 01

read[1] read[2] read[0] write[0] write[2] write[3] Var Inc write[1] write[2] write[3] read[1] write[1] write[0] read[0] write[1] write[2] write[3] read[0] / write[0] © Oscar Nierstrasz 12 Safety and Synchronization

© Oscar Nierstrasz 13 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

© Oscar Nierstrasz Safety and Synchronization 14 Concurrent behaviour Without synchronization, concurrent threads may interfere: ||ParInc = ({a,b}::Var || a:Inc || b:Inc). 01

© Oscar Nierstrasz Safety and Synchronization 15 Locking Locks are used to make a critical section atomic: LOCK=( acquire -> release -> LOCK ). INC=(acquire ->read[v:0..N-1] ->write[v+1] ->release ->STOP) +VarAlpha. 01

© Oscar Nierstrasz Safety and Synchronization 16 Synchronization Processes can synchronize critical sections by sharing a lock: ||ParInc2 = ({a,b}::VAR || {a,b}::LOCK || a:INC || b:INC). 01

Synchronization in Java © Oscar Nierstrasz Safety and Synchronization 17 synchronized T m() { // method body } T m() { synchronized (this) { // method body } Java Threads also synchronize using locks: is just convenient syntax for: Every object has a lock, and Threads may use them to synchronize with each other.

© Oscar Nierstrasz 18 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

© Oscar Nierstrasz Safety and Synchronization 19 Busy-Wait Mutual Exclusion Protocol P1 sets enter1 := true when it wants to enter its CS, but sets turn := “P2” to yield priority to P2 Is this protocol correct? Is it fair? Deadlock-free? process P1 loop enter1 := true turn := “P2” while enter2 and turn = “P2” do skip Critical Section enter1 := false Non-critical Section end process P2 loop enter2 := true turn := “P1” while enter1 and turn = “P1” do skip Critical Section enter2 := false Non-critical Section end

© Oscar Nierstrasz Safety and Synchronization 20 Atomic read and write We can model integer and boolean variables as processes with atomic read and write actions: range T = 1..2 Var = Var[1], Var[u:T] = ( read[u] -> Var[u] | write[v:T]-> Var[v]). set Bool = {true,false} BOOL(Init='false) = BOOL[Init], BOOL[b:Bool] = ( is[b]-> BOOL[b] | setTo[x:Bool]-> BOOL[x]).

© Oscar Nierstrasz Safety and Synchronization 21 Modelling the busy-wait protocol Each process performs two actions in its CS: P1 = ( enter1.setTo['true] -> turn.write[2] -> Gd1), Gd1 = ( enter2.is['false] -> CS1 | enter2.is['true] -> ( turn.read[1] -> CS1 | turn.read[2] -> Gd1)), CS1 = ( a -> b -> enter1.setTo['false] -> P1). P2 = ( enter2.setTo['true] -> turn.write[1] -> Gd2), Gd2 = ( enter1.is['false] -> CS2 | enter1.is['true] -> ( turn.read[2] -> CS2 | turn.read[1] -> Gd2)), CS2 = ( c -> d -> enter2.setTo['false] -> P2). ||BusyWait =

© Oscar Nierstrasz Safety and Synchronization 22 Busy-wait composition Very pretty, but how do we know there are no errors?! 01

© Oscar Nierstrasz Safety and Synchronization 23 Checking for errors We can check for errors by composing our system with an agent that moves to the ERROR state if atomicity is violated: What happens if we break the protocol? Ok=( a -> ( c -> ERROR | b -> Ok ) | c -> ( a -> ERROR | d -> Ok)). ||BusyWaitOK = (enter1:BOOL||enter2:BOOL||turn:Var||P1||P2||Ok). 01

© Oscar Nierstrasz 24 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

© Oscar Nierstrasz Safety and Synchronization 25 Safety revisited A safety property asserts that nothing bad happens Use ERROR process (-1) to detect erroneous behaviour Trace to property violation in ACTUATOR: command ACTUATOR =( command->ACTION), ACTION=( respond->ACTUATOR | command->ERROR). 01

© Oscar Nierstrasz Safety and Synchronization 26 Safety — property specification ERROR conditions state what is not required In complex systems, it is usually better to specify directly what is required. Trace to property violation in SAFE_ACTUATOR: respond property SAFE_ACTUATOR = ( command -> respond -> SAFE_ACTUATOR ). 01

© Oscar Nierstrasz Safety and Synchronization 27 Checking Busy-Wait (revisited) Ok is a deterministic process that specifies which traces are safe — everything else is in ERROR. Contrast: property Ok=( a -> b -> Ok | c -> d -> Ok ). Ok = ( a -> ( c -> ERROR | b -> Ok ) | c -> ( a -> ERROR | d -> Ok )). 01

© Oscar Nierstrasz Safety and Synchronization 28 Safety properties A safety property P defines a deterministic process that asserts that any trace including actions in the alphabet of P is accepted by P. Transparency of safety properties:  Since all actions in the alphabet of a property are eligible choices, composing a property with a set of processes does not affect their correct behaviour.  If a behaviour can occur which violates the safety property, then ERROR is reachable.

© Oscar Nierstrasz Safety and Synchronization 29 Transparency Why must properties be deterministic to be transparent? Consider: Is a->b allowed or not? property P = (a->b->P|a->c->P). 01

© Oscar Nierstrasz Safety and Synchronization 30 Safety properties How can we specify that some action, disaster, never occurs? A safety property must be specified so as to include all the acceptable, valid behaviours in its alphabet. property CALM = STOP + {disaster}.

© Oscar Nierstrasz 31 Roadmap  Modelling interaction in FSP  Safety — synchronizing critical sections  Locking for atomicity  The busy-wait mutual exclusion protocol  Checking Safety properties  Conditional synchronization Safety and Synchronization

Conditional synchronization © Oscar Nierstrasz Safety and Synchronization 32 LOCK = ( acquire -> release -> LOCK ). const N = 2 Slot =( put[v:0..N] ->get[v] ->Slot ). Similarly, a one-slot buffer delays a put request if it is full and delays a get request if it is empty: A lock delays an acquire request if it is already locked:

© Oscar Nierstrasz Safety and Synchronization 33 Producer/Consumer composition Producer = ( put[0] -> put[1] -> put[2] -> Producer ). Consumer = ( get[x:0..N] -> Consumer ). ||Chain =( Producer || Slot || Consumer ) 01

© Oscar Nierstrasz Safety and Synchronization 34 Wait and notify A Java object whose methods are all synchronized behaves like a monitor Within a synchronized method or block:  wait() suspends the current thread, releasing the lock  notify() wakes up one thread waiting on that object  notifyAll() wakes up all threads waiting on that object NB: Outside of a synchronized block, wait() and notify() will raise an IllegalMonitorStateException Always use notifyAll() unless you are sure it doesn’t matter which thread you wake up!

© Oscar Nierstrasz Safety and Synchronization 35 Slot (put) class Slot implements Buffer { private Value slotVal;// initially null public synchronized void put(Value val) { while (slotVal != null) { try { wait(); }// become NotRunnable catch (InterruptedException e) { } } slotVal = val; notifyAll();// make waiting threads Runnable return; }... interface Buffer { public void put(Value val); public Value get(); } Slot

© Oscar Nierstrasz Safety and Synchronization CP 3.36 Slot (get)... public synchronized Value get() { Value rval; while (slotVal == null) { try { wait(); } catch (InterruptedException e) { } } rval = slotVal; slotVal = null; notifyAll(); return rval; }

Slots and Active Objects © Oscar Nierstrasz Safety and Synchronization 37 Active objects have their own thread. Producers and Consumers are active objects that communicate and synchronize through a shared buffer.

© Oscar Nierstrasz Safety and Synchronization 38 Active objects abstract class ActiveObject extends Thread { protected int count; ActiveObject(String name, int count) { super(name); this.count = count; } public void run() { int i; for (i=1;i<=count;i++) { this.action(i); } protected abstract void action(int n); } An active object has a thread of its own. Slot

© Oscar Nierstrasz Safety and Synchronization 39 Producer in Java A generic Producer puts count messages to the slot: abstract class Producer extends ActiveObject { protected Buffer slot; Producer(String name, int count, Buffer slot) { super(name, count); this.slot = slot; } protected void action(int n) { slot.put(produce(n)); } protected abstract Value produce(int n); } Slot

© Oscar Nierstrasz Safety and Synchronization 40 Consumer in Java... and the Consumer gets them: abstract class Consumer extends ActiveObject { protected Buffer slot; Consumer(String name, int count, Buffer slot) { super(name, count); this.slot = slot; } protected void action(int n) { consume(n, slot.get()); } protected abstract void consume(int n, Value val); }

Fruit producers and consumers © Oscar Nierstrasz Safety and Synchronization 41 public class ProducerConsumerDemo {... private class FruitProducer extends Producer { protected String wares; FruitProducer(...) {... } protected String produce(int n) { String message; message = wares + "(" + n + ")"; System.out.println(getName() + " put " + message); return message; } private class FruitConsumer extends Consumer {... }

© Oscar Nierstrasz Safety and Synchronization 42 Composing Producers and Consumers Peter put apple (1) Carla got apple (1) Paula put orange(1) Cris got orange(1) Patricia put banana(1) Carla got banana(1) Peter put apple (2) Cris got apple (2) Patricia put banana(2) Carla got banana(2) Peter put apple (3) Cris got apple (3) Paula put orange(2) Carla got orange(2) Patricia put banana(3) Cris got banana(3) Peter put apple (4) Cris got apple (4) Peter put apple (5) Carla got apple (5) Paula put orange(3) Cris got orange(3) Patricia put banana(4) Cris got banana(4) Patricia put banana(5) Cris got banana(5) Paula put orange(4) Cris got orange(4) Paula put orange(5) Cris got orange(5) public class ProducerConsumerDemo { static int COUNT = 5;... public void demo() { Buffer slot = new Slot (); new FruitProducer("Peter", COUNT, slot, "apple").start(); new FruitProducer("Paula", COUNT, slot, "orange").start(); new FruitProducer("Patricia", COUNT, slot, "banana").start(); new FruitConsumer("Carla", COUNT, slot).start(); new FruitConsumer("Cris", 2*COUNT, slot).start(); }... } Multiple producers and consumers may share the buffer:

© Oscar Nierstrasz Safety and Synchronization 43 What you should know!  How do you model interaction with FSP?  What is a critical section? What is critical about it?  Why don’t sequential programs need synchronization?  How do locks address safety problems?  What primitives do you need to implement the busy-wait mutex protocol?  How can you use FSP to check for safety violations?  What happens if you call wait or notify outside a synchronized method or block?  When is it safe to use notifyAll()?  What are safety properties? How are they modelled in FSP?

© Oscar Nierstrasz Safety and Synchronization 44 Can you answer these questions?  What is an example of an invariant that might be violated by interfering, concurrent threads?  What constitute atomic actions in Java?  Can you ensure safety in concurrent programs without using locks?  When should you use synchronize(this) rather than synchronize(someObject)?  Is the busy-wait mutex protocol fair? Deadlock-free?  How would you implement a Lock class in Java?  Why is the Java Slot class so much more complex than the FSP Slot specification?  How would you manually check a safety property?  Why must safety properties be deterministic to be transparent?

License © Oscar Nierstrasz ESE — Introduction Attribution-ShareAlike 3.0 Unported You are free: to Share — to copy, distribute and transmit the work to Remix — to adapt the work Under the following conditions: Attribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work). Share Alike. If you alter, transform, or build upon this work, you may distribute the resulting work only under the same, similar or a compatible license. For any reuse or distribution, you must make clear to others the license terms of this work. The best way to do this is with a link to this web page. Any of the above conditions can be waived if you get permission from the copyright holder. Nothing in this license impairs or restricts the author's moral rights.