Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 6:Computational Model (based on work with Piotr Nienaltowski)

Slides:



Advertisements
Similar presentations
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 5.
Advertisements

SCOOP: Simple Concurrent Object-Oriented Programming Extend the pure, strongly typed, object-oriented language Eiffel with a general and powerful concurrency.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 10: Advanced Object-Oriented Mechanisms (based on.
2 nd Microsoft Rotor Workshop, Pisa, April 23-25, SCOOPLI for.NET: a library for concurrent object-oriented programming Volkan Arslan, Piotr Nienaltowski.
SCOOP on.NET Volkan Arslan Chair of Software Engineering ETH Zurich, Switzerland
Concurrency Important and difficult (Ada slides copied from Ed Schonberg)
Chair of Software Engineering The alias calculus Bertrand Meyer ITMO Software Engineering Seminar June 2011.
Silberschatz, Galvin and Gagne ©2013 Operating System Concepts – 9 th Edition Chapter 5: Process Synchronization.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 7: References and Assignment.
Multithreaded Programs in Java. Tasks and Threads A task is an abstraction of a series of steps – Might be done in a separate thread – Java libraries.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 7: SCOOP Type System (based on work with Piotr Nienaltowski)
Chair of Software Engineering PPoPP 2003, , San Diego SCOOP it up! Piotr Nienaltowski Chair of Software Engineering, ETH Zurich, Switzerland.
Monitors Chapter 7. The semaphore is a low-level primitive because it is unstructured. If we were to build a large system using semaphores alone, the.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering OOSC Lecture 20 - Concurrency Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Piotr Nienaltowski, SCOOP Simple Concurrent Object-Oriented Programming.
Chair of Software Engineering SCOOP: an introduction Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland
Chair of Software Engineering ATOT - Lecture 25, 30 June Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
DISTRIBUTED AND HIGH-PERFORMANCE COMPUTING CHAPTER 7: SHARED MEMORY PARALLEL PROGRAMMING.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 15: Exception handling.
Chair of Software Engineering Piotr Nienaltowski, , Concurrent Object-Oriented Programming Bertrand Meyer, Piotr Nienaltowski.
1 SWE Introduction to Software Engineering Lecture 23 – Architectural Design (Chapter 13)
Chair of Software Engineering Piotr Nienaltowski, , Concurrent Object-Oriented Programming Bertrand Meyer, Piotr Nienaltowski.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chair of Software Engineering SCOOP for ROTOR Bertrand Meyer Capstone (ROTOR final workshop), 2005 © Bertrand Meyer, 2005.
Chair of Software Engineering ATOT - Lecture 26, 30 June Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Programming Language Semantics Java Threads and Locks Informal Introduction The Java Specification Language Chapter 17.
SCOOP: Simple Concurrent Object-Oriented Programming Piotr Nienaltowski, Volkan Arslan, Bertrand Meyer presented by: Mark Schall.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Exercise Session 2: Introduction.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 4: The Interface of a Class.
Chapter 11: Distributed Processing Parallel programming Principles of parallel programming languages Concurrent execution –Programming constructs –Guarded.
Chair of Software Engineering ATOT - Lecture 25, 30 June Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 9: Contracts and Inheritance (based on work with.
02/23/2004CSCI 315 Operating Systems Design1 Process Synchronization Notice: The slides for this lecture have been largely based on those accompanying.
Synchronization in Java Fawzi Emad Chau-Wen Tseng Department of Computer Science University of Maryland, College Park.
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 6: Object Creation.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 2: an overview of SCOOP.
Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, SCOOP update and proposed extensions Piotr Nienaltowski.
Chair of Software Engineering ATOT - Lecture 7, 23 April Advanced Topics in Object Technology Bertrand Meyer.
Chair of Software EngineeringOOSC – Summer Semester 2005 Object-Oriented Software Construction Bertrand Meyer Lecture 19: SCOOP Simple Concurrent Object-Oriented.
Subclasses and Subtypes CMPS Subclasses and Subtypes A class is a subclass if it has been built using inheritance. ▫ It says nothing about the meaning.
Concurrency Recitation – 2/24 Nisarg Raval Slides by Prof. Landon Cox.
Monitor  Giving credit where it is due:  The lecture notes are borrowed from Dr. I-Ling Yen at University of Texas at Dallas  I have modified them and.
1 Thread II Slides courtesy of Dr. Nilanjan Banerjee.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
SWE 619 © Paul Ammann Procedural Abstraction and Design by Contract Paul Ammann Information & Software Engineering SWE 619 Software Construction cs.gmu.edu/~pammann/
Lecture 3 Process Concepts. What is a Process? A process is the dynamic execution context of an executing program. Several processes may run concurrently,
ABSTRACT The real world is concurrent. Several things may happen at the same time. Computer systems must increasingly contend with concurrent applications.
Contracts for Concurrency - Contracts & Inheritance Aryabrata Basu University of Georgia.
COMP 111 Threads and concurrency Sept 28, Tufts University Computer Science2 Who is this guy? I am not Prof. Couch Obvious? Sam Guyer New assistant.
Design by Contract Ranga Rodrigo based on Mark Priestley's Lectures.
CY2003 Computer Systems Lecture 04 Interprocess Communication.
Synchronicity Introduction to Operating Systems: Module 5.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
13-1 Chapter 13 Concurrency Topics Introduction Introduction to Subprogram-Level Concurrency Semaphores Monitors Message Passing Java Threads C# Threads.
DBC NOTES. Design By Contract l A contract carries mutual obligations and benefits. l The client should only call a routine when the routine’s pre-condition.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Tutorial 2: Homework 1 and Project 1
SCOOPLI for .NET: a library for concurrent object-oriented programming
“Language Mechanism for Synchronization”
Simple Concurrent Object-Oriented Programming
Threading And Parallel Programming Constructs
Concurrency: Mutual Exclusion and Process Synchronization
Monitor Giving credit where it is due:
CSE 153 Design of Operating Systems Winter 19
CS561 Computer Architecture Hye Yeon Kim
Presentation transcript:

Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 6:Computational Model (based on work with Piotr Nienaltowski)

2 Basic Idea of OO Computation To perform a computation is To apply certain actions To certain objects Using certain processors ActionObject Processor

3 Processors Processor: a thread of control supporting sequential execution of instructions on one or several objects. All actions on a given object are executed by its handling processor. No shared access to objects! We say that the object is handled by its processor. This relationship is fixed, i.e. we do not consider migration of objects between processors. Each processor, together with all object it owns, can be seen as a sequential subsystem. A (concurrent) software system is composed of such subsystems. By design a SCOOP system is free of low-level data races.

4 Processors P1 o1 o3 o2o4 P2 o5 o9 o7 P3 o11 o8 o6o12

5 Processors Processor is an abstract concept Do not confuse it with a CPU! A processor can be implemented as: Process Thread Web service.NET AppDomain …

6 Synchronous Feature Call f (a: A) require a /= Void do … end c x x: X previous_instruction x.f (a) next_instruction P1 c x

7 Asynchronous Feature Call f (a: A) require a /= Void do … end c x x: separate X previous_instruction x.f (a) next_instruction P1 c P2 x

8 Separate Objects Calls to non-separate objects are synchronous. Calls to separate objects are asynchronous. QUIZ: Which objects are separate here? P1P1 o1 P2 o2 o3

9 Separate Entities Separate entities are declared with separate keyword as in x: separate X. Does a separate entity always denote a separate object? Separate entities denote potentially separate objects. P1 o1 P2 o2 o3 x y y y: separate X r (x: separate X) do y := x.y -- Is y a separate entity? -- Does it denote a separate object? end

10 Synchronization Processors are sequential. Concurrency is achieved by interplay of several processors. Processors need to synchronize. Three forms of synchronization in SCOOP mutual exclusion condition synchronization wait-by-necessity

11 Why do we need mutual exclusion? P1 o1 P2 o2 o3 my_stack y P3 o6 o8 y my_stack -- P1 my_stack.push (5) y := my_stack.top -- P3 my_stack.push (100) y := my_stack.top

12 Mutual Exclusion in SCOOP Require target of separate call to be formal argument of enclosing routine. Body (do … end) of enclosing routine is a critical section with respect to its separate formal arguments. push_and_retrieve (s: separate STACK [INTEGER]; value: INTEGER) -- Push value on top of s then retrieve top of s and assign it to y. do s.push (value) y := s.top end my_stack: separate STACK [INTEGER] … push_and_retrieve (my_stack, 5) -- Now we are we sure that y=5 No other processor can access s in the meantime.

13 Wait Rule A routine call with separate arguments will execute when all corresponding processors are available. The processors are held exclusively for the duration of the routine.

14 Condition Synchronization Very often client only wants to execute certain feature if some condition (guard) is true. store (buffer: separate BOUNDED_BUFFER [INTEGER]; value: INTEGER) is -- Store value into buffer. require buffer_not_full: not buffer.is_full do buffer.put (value) end my_buffer: separate BOUNDED_BUFFER [INTEGER] … store (my_buffer, 5) Hey, it’s a precondition, not a guard! How should it work?

15 From Preconditions to Wait-Conditions store (buffer: BUFFER [INTEGER]; value: INTEGER) -- Store value into buffer. require buffer_not_full: not buffer.is_full value > 0 do buffer.put (value) ensure buffer_not_empty: not buffer.is_empty end... store (my_buffer, 5) precondition postcondition

16 Why new semantics? Preconditions are obligations that the client has to satisfy before the call. The fulfillment of the precondition is not only in our hands. if not my_buffer.is_full and then 5 > 0 then store (my_buffer, 5) end Is the precondition of store satisfied?

17 Wait Rule Revisited Wait Rule A routine call with separate arguments will execute when all corresponding processors are available and the precondition is satisfied. The processors are held exclusively for the duration of the routine.

18 Resynchronizing Clients and Suppliers … x.f x.g (a) y.f … Pc Px Py x.f x.g(a) y.f

19 Wait By Necessity There is no explicit mechanism for resynchronization after separate call. The client will only wait when it needs to. This is called wait-by-necessity. x.f; x.g (a); y.f … value := x.some_query wait here

20 Do we really need to wait? Can we do better than that? It does not change the basic SCOOP model. Consider it to be an optimisation x.f; x.g (a); y.f … value := x.some_query x.f; y.f value := value + 1 We only need to wait here.

21 Too much Locking r (x: separate X; y: separate Y; z: separate Z) require some_precondition local my_y: separate Y my_z: separate Z do x.f my_y := y x.g my_z := z s (z) end

22 Eager Locking Eager locking policy has two major drawbacks Increases danger of deadlock References cannot be passed around without locking the corresponding objects; programmers have no real control over the locks

23 Wait Rule Revisited Wait Rule A routine call with separate arguments will execute when all processors of attached formal arguments are available and the precondition is satisfied. The processors are held exclusively for the duration of the routine. Together with the valid target rule the wait rule ensures the absence of high-level data races.

24 Just enough Locking r (x: separate X; y: detachable separate Y; z: detachable separate Z) require some_precondition local my_y: detachable separate Y my_z: detachable separate Z do x.f my_y := y x.g my_z := z s (z) end

25 Summary Software system is composed of several processors. Processors are sequential; concurrency is achieved through their interplay. Separate entity denotes a potentially separate object. Calls to non-separate objects are synchronous. Calls to separate objects are asynchronous.

26 Summary mutual exclusion Locking through argument passing Routine body is critical section Flexible locking increased parallelism condition synchronization wait-semantics for preconditions re-synchronisation of client and supplier: wait-by-necessity