Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 10: Advanced Object-Oriented Mechanisms (based on.

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.
Programming with App Inventor Computing Institute for K-12 Teachers Summer 2012 Workshop.
Modules Program is built out of components. Each component defines a set of logically related entities (strong internal coupling) A component has a public.
1 Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 13.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Exercise Session 1: Eiffel Introduction.
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
Chair of Software Engineering Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Lecture 7: References and Assignment.
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.
Chair of Software Engineering Constants, once routines, and helper functions these slides contain advanced material and are optional.
1 Design by Contract Building Reliable Software. 2 Software Correctness Correctness is a relative notion  A program is correct with respect to its specification.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
Chair of Software Engineering Piotr Nienaltowski, SCOOP Simple Concurrent Object-Oriented Programming.
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 Lecture 15: Exception handling.
Chair of Software Engineering Piotr Nienaltowski, , Concurrent Object-Oriented Programming Bertrand Meyer, Piotr Nienaltowski.
Chair of Software Engineering Piotr Nienaltowski, , Concurrent Object-Oriented Programming Bertrand Meyer, Piotr Nienaltowski.
Chair of Software Engineering 1 Concurrent Object-Oriented Programming Arnaud Bailly, Bertrand Meyer and Volkan Arslan.
Chair of Software Engineering 1 Concurrent Object-Oriented Programming Arnaud Bailly, Bertrand Meyer and Volkan Arslan.
1 Advanced Material The following slides contain advanced material and are optional.
User Level Interprocess Communication for Shared Memory Multiprocessor by Bershad, B.N. Anderson, A.E., Lazowska, E.D., and Levy, H.M.
1: Operating Systems Overview
Chair of Software Engineering ATOT - Lecture 26, 30 June Advanced Topics in Object Technology Bertrand Meyer.
Server Architecture Models Operating Systems Hebrew University Spring 2004.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
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.
Chair of Software Engineering 1 Introduction to Programming Tuples and Agents Exercise Session 1 and 2 December 2008.
Chair of Software Engineering ATOT - Lecture 20, 11 June Advanced Topics in Object Technology Bertrand Meyer.
User-Level Interprocess Communication for Shared Memory Multiprocessors Brian N. Bershad, Thomas E. Anderson, Edward D. Lazowska, and Henry M. Levy Presented.
1 I/O Management in Representative Operating Systems.
Chair of Software Engineering Concurrent Object-Oriented Programming Prof. Dr. Bertrand Meyer Lecture 6:Computational Model (based on work with Piotr Nienaltowski)
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 Einführung in die Programmierung Introduction to Programming Prof. Dr. Bertrand Meyer Exercise Session 11.
1 Lecture 4: Threads Operating System Fall Contents Overview: Processes & Threads Benefits of Threads Thread State and Operations User Thread.
LOGO OPERATING SYSTEM Dalia AL-Dabbagh
Operating System Review September 10, 2012Introduction to Computer Security ©2004 Matt Bishop Slide #1-1.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
 Expression Tree and Objects 1. Elements of Python  Literals, Strings, Tuples, Lists, …  The order of file reading  The order of execution 2.
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.
Basic Scheme February 8, 2007 Compound expressions Rules of evaluation Creating procedures by capturing common patterns.
CS533 – Spring Jeanie M. Schwenk Experiences and Processes and Monitors with Mesa What is Mesa? “Mesa is a strongly typed, block structured programming.
1/33 Basic Scheme February 8, 2007 Compound expressions Rules of evaluation Creating procedures by capturing common patterns.
Operating Systems (CS 340 D) Dr. Abeer Mahmoud Princess Nora University Faculty of Computer & Information Systems Computer science Department.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Lecture 5: RPC (exercises/questions). 26-Jun-16COMP28112 Lecture 52 First Six Steps of RPC TvS: Figure 4-7.
Tutorial 2: Homework 1 and Project 1
Processes and threads.
Basic Scheme February 8, 2007 Compound expressions Rules of evaluation
Advanced Operating Systems CIS 720
Topic 3 (Textbook - Chapter 3) Processes
SCOOPLI for .NET: a library for concurrent object-oriented programming
Advanced Topics in Concurrency and Reactive Programming: Asynchronous Programming Majeed Kassis.
Operating Systems (CS 340 D)
Simple Concurrent Object-Oriented Programming
Chapter 4: Multithreaded Programming
Operating Systems (CS 340 D)
Lecture 6: RPC (exercises/questions)
Introduction to the Lab
Chapter 3: Process Concept
Lecture 6: RPC (exercises/questions)
Lecture 7: RPC (exercises/questions)
Lecture 12 Input/Output (programmer view)
Presentation transcript:

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

2 What is an agent?  An agent represents an operation ready to be called.  Agents can be created by one object, passed to another one, and called by the latter x: X op1: ROUTINE [X, TUPLE] op1 := agent x f op1 call ([])

3 What is an agent? Arguments can be closed (fixed) or open. They are based on generic classes: op1 := agent io.put_string (”Hello World!”) op1.call ([]) op1 := agent io.put_string (?) op1 call ([”Hello World!”]) Empty tuple as argument One-argument tuple ROUTINE [BASE_TYPE, OPEN_ARGS -> TUPLE] PROCEDURE [BASE_TYPE, OPEN_ARGS -> TUPLE] FUNCTION [BASE_TYPE, OPEN_ARGS -> TUPLE, RESULT_TYPE]

4 Use of agents Object-oriented wrappers for operations  Strongly-typed function pointers (C++)  Similar to.NET delegates Used in event-driven programming  Subscribe an action to an event type  The action is executed when event occurs Loose coupling of software components Replace several patterns  Observer  Visitor  Model - View – Controller...

5 Problematic Agents Which processor should handle an agent? Is it the target processor or the client processor? Let‘s assume it is the client processor. x a1 target P1P1 P2P2 separate reference non-separate reference a1: PROCEDURE [separate ANY, TUPLE] x: separate X... a1 := agent x.f a1.call ([]) Like x.f without locking x Traitor

6 Let’s make the agent separate! The agent needs to be on the target processor. x a1 target P1P1 P2P2 separate reference non-separate reference a1: separate PROCEDURE [X, TUPLE] x: separate X... a1 := agent x.f a1.call ([]) This agent will be handled by x’s processor Invalid

7 Let’s make the agent separate! No special type rules for separate agents Semantic rule: an agent is created on its target’s processor Agents pass processors’ boundaries just as other objects do a1: separate PROCEDURE [X, TUPLE] x: separate X a1 := agent x.f call (a1) call (an_agent: separate PROCEDURE [ANY, TUPLE]) do an_agent.call ([]) end Valid separate call

8 First benefit: convenience Without agents, enclosing routines are necessary for every separate call. With agents, we can write a universal enclosing routine. x1: separate X r (x1) s (x1) s (x: separate X) do x.g (5, ”Hello”) end r (x: separate X) do x.f end call (agent x1.f); call (agent x1.g (5, ”Hello”)) call (an_agent: separate PROCEDURE [ANY, TUPLE]) -- Universal enclosing routine. do an_agent.call ([]) end

9 Second benefit: full asynchrony Without agents, full asynchrony cannot be achieved With agents it works x1, y1: separate X r (x1) do_local_stuff r (x: separate X) do x.f end Blocking Asynchronous asynch (agent x1.f) do_local_stuff asynch (a: detachable separate PROCEDURE [ANY, TUPLE]) -- Call a asynchronously. do... end Non-blocking

10 Full asynchrony x1 P1P1 P2P2 target P3P3 feature_to_execute (EXECUTOR) separate reference non-separate reference An executor object gets created on another processor to execute the agent asynchronously.

11 Full asynchrony The feature asynch is implemented in the class CONCURRENCY An asynchronous call on a non-separate targets (including Current) will be executed when the current processor becomes idle. asynch (an_agent: detachable separate PROCEDURE [ANY, TUPLE]) -- Call `an_agent’ asynchronously. -- Note that `an_agent’ is not locked. local executor: separate EXECUTOR do create executor.make (an_agent) launch(executor) end

12 Separate agent benefit 3: waiting faster What if x1 or y1 is busy? What if x1.b is false but y1.b is true? What if evaluation of x1.b takes ages whereas y1.b evaluates very fast? x1, y1: separate X if or_else (x1, y1) then... end or_else (x, y: separate X): BOOLEAN do Result := x.b or else y.b end

13 Waiting faster parallel_or (a1, a2: detachable separate FUNCTION [ANY, TUPLE, BOOLEAN]): BOOLEAN -- Result of `a1’ or else `a2’ computed in parallel. local answer_collector: separate ANSWER_COLLECTOR [BOOLEAN] do create answer_collector.make (a1, a2) Result := answer (answer_collector) end if parallel_or (agent x1.b, agent y1.b) then... end answer (ac: separate ANSWER_COLLECTOR [BOOLEAN]): BOOLEAN -- Result returned by `an_answer_collector’. require answer_ready: ac.is_ready do Result ?= ac.answer end

14 Waiting faster x1 y1 (CLIENT) (X) P1P1 P2P2 b b P3P3 (FUNCTION [...]) target (FUNCTION [...]) target P4P4 P5P5 query (EVALUATOR [...]) answer_c ollector query (EVALUATOR [...]) answer_c ollector P6P6 answer (ANSWER_COLLECTOR[...]) ans_col

15 3 rd Benefit: Waiting Faster Parallel or, parallel and,... Launch n jobs and wait for first result, etc. Implemented in class CONCURRENCY Relies on generic classes ANSWER_COLLECTOR [RESULT_TYPE] EVALUATOR [RESULT_TYPE]

16 Conclusions Agents and concurrency Tricky at first; easy in the end Agents built on separate calls are separate Open-target agents are non-separate on creation Agents treated just like any other object Advantages brought by agents Convenience: “universal” enclosing routine for single calls Full asynchrony: non-blocking calls Truly parallel wait All these are implemented as library mechanisms

17 Once Functions Similar to constants Always return the same value Lazy evaluation Body executed on first access Once per thread or once per object semantic. Examples of use Heavy computations Stock market statistics Common contact point for objects of one type Feature io in class ANY

18 Once functions in a concurrent context Is once-per-system semantics always correct? Separate functions are once-per-system. Non-separate functions are once-per-processor. local_printer: PRINTER once printer_pool.item (Current.location) end barrier: separate BARRIER once create Result.make (3) end

19 Genericity Entities of generic types may be separate Actual generic parameters may be separate All combinations are meaningful and useful Separateness is relative to object of generic class, e.g. elements of list: separate LIST [BOOK] are non- separate with respect to (w.r.t) list but separate w.r.t. Current. Type combiners apply. list: LIST [BOOK] list: separate LIST [BOOK] list: LIST [separate BOOK] list: separate LIST [separate BOOK]