Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 1 SCOOP update and proposed extensions 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.
Control Structures Ranga Rodrigo. Control Structures in Brief C++ or JavaEiffel if-elseif-elseif-else-end caseinspect for, while, do-whilefrom-until-loop-end.
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
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.
ISBN Chapter 3 Describing Syntax and Semantics.
Chair of Software Engineering OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer.
“THREADS CANNOT BE IMPLEMENTED AS A LIBRARY” HANS-J. BOEHM, HP LABS Presented by Seema Saijpaul CS-510.
Chair of Software Engineering OOSC Lecture 20 - Concurrency Object-Oriented Software Construction Bertrand Meyer.
1 Basic abstract interpretation theory. 2 The general idea §a semantics l any definition style, from a denotational definition to a detailed interpreter.
Chair of Software Engineering Piotr Nienaltowski, SCOOP Simple Concurrent Object-Oriented Programming.
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.
1 Advanced Material The following slides contain advanced material and are optional.
CS 330 Programming Languages 09 / 13 / 2007 Instructor: Michael Eckmann.
Chair of Software Engineering ATOT - Lecture 26, 30 June Advanced Topics in Object Technology Bertrand Meyer.
SCOOP: Simple Concurrent Object-Oriented Programming Piotr Nienaltowski, Volkan Arslan, Bertrand Meyer presented by: Mark Schall.
Covariance & anchored types 2 Covariance? Within the type system of a programming language, a typing rule or a type conversion operator is*:
Chair of Software Engineering Avoid a void Bertrand Meyer ©Bertrand Meyer, 2008.
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 OOSC - Summer Semester Object-Oriented Software Construction Bertrand Meyer Lecture 6: Genericity.
1 Sharing Objects – Ch. 3 Visibility What is the source of the issue? Volatile Dekker’s algorithm Publication and Escape Thread Confinement Immutability.
CS 330 Programming Languages 09 / 16 / 2008 Instructor: Michael Eckmann.
Describing Syntax and Semantics
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 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.
1 CISC181 Introduction to Computer Science Dr. McCoy Lecture 19 Clicker Questions November 3, 2009.
Imperative Programming
10 Conversion. Let’s start with conformance Conformance determines when a type may be used in lieu of another. Conformance relies on inheritance. The.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
CSC3315 (Spring 2009)1 CSC 3315 Programming Languages Hamid Harroud School of Science and Engineering, Akhawayn University
1 Abstraction  Identify important aspects and ignore the details  Permeates software development programming languages are abstractions built on hardware.
© The McGraw-Hill Companies, 2006 Chapter 4 Implementing methods.
1 Concurrent Languages – Part 1 COMP 640 Programming Languages.
Copyright © 2005 Elsevier Chapter 8 :: Subroutines and Control Abstraction Programming Language Pragmatics Michael L. Scott.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Introduction to Concurrency.
More About Classes Ranga Rodrigo. Information hiding. Copying objects.
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.
Chair of Software Engineering 1 Introduction to Programming Bertrand Meyer Exercise Session October 2008.
Topic 1 Object Oriented Programming. 1-2 Objectives To review the concepts and terminology of object-oriented programming To discuss some features of.
ICS 313: Programming Language Theory Chapter 13: Concurrency.
Shared Memory Consistency Models. SMP systems support shared memory abstraction: all processors see the whole memory and can perform memory operations.
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.
Ceg860 (Prasad)L17IT1 Inheritance Techniques Subcontracting Anchored Types.
Copyright © 2004, Keith D Swenson, All Rights Reserved. OASIS Asynchronous Service Access Protocol (ASAP) Tutorial Overview, OASIS ASAP TC May 4, 2004.
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.
Prof. Necula CS 164 Lecture 171 Operational Semantics of Cool ICOM 4029 Lecture 10.
CPSC 252 ADTs and C++ Classes Page 1 Abstract data types (ADTs) An abstract data type is a user-defined data type that has: private data hidden inside.
1 Programming with Shared Memory - 3 Recognizing parallelism Performance issues ITCS4145/5145, Parallel Programming B. Wilkinson Jan 22, 2016.
© Bertrand Meyer and Yishai Feldman Notice Some of the material is taken from Object-Oriented Software Construction, 2nd edition, by Bertrand Meyer (Prentice.
Macro Processor Design Options Recursive Macro Expansion General-Purpose Macro Processors Macro Processing within Language Translators.
Tutorial 2: Homework 1 and Project 1
Design by Contract Jim Fawcett CSE784 – Software Studio
Design by Contract Jim Fawcett CSE784 – Software Studio
SCOOPLI for .NET: a library for concurrent object-oriented programming
Compilers Principles, Techniques, & Tools Taught by Jing Zhang
Chapter 9 :: Subroutines and Control Abstraction
Concurrency: Mutual Exclusion and Process Synchronization
Foundations and Definitions
Programming with Shared Memory Specifying parallelism
CSE 153 Design of Operating Systems Winter 2019
Presentation transcript:

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, SCOOP update and proposed extensions Piotr Nienaltowski

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Outline  Refresher on SCOOP  What separate really means  Locking  Use of detachable and attached types  Lock passing  Type system for SCOOP  Contracts in SCOOP  How to get rid of deadlocks

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Refresher on SCOOP  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 memory!!!  We say that the object is owned by the handling processor  this ownership relation 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.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Software system P1 o1 o3 o2o4 P2 o5 o9 o7 P3 o11 o8 o6o12 P1 handles o1, o2, o3, o4 P2 handles o5, o7, o9 P3 handles o6, o8, o11, o12 denotes o1’s owner = P1

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Separate objects  Calls to non-separate objects are synchronous  Calls to separate objects are asynchronous P1 o1 P2 o2 o3  QUIZ: Which objects are separate?

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Separate entities  Separate entities are declared with separate keyword separate class C feature y: C … y := Current end  Does a separate entity always denote a separate object? x: C -- Separate or not z: separate C … z := x.y…-- Is y a separate entity? -- Does it denote a separate object?  Separate entities denote potentially separate objects P1 o1 P2 o2 o3 x y y

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Separate entities  Separate entities are declared with separate keyword class C feature y: separate C y := Current Current.f y.f end  Does a separate entity always denote a separate object? x: C -- Separate or not z: separate C … z := x.y…-- Is y a separate entity? -- Does it denote a separate object?  Separate entities denote potentially separate objects P1 o1 P2 o2 o3 x y y

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, What separate really means  Separateness is a property of objects, not classes!  Objects can be separate (w.r.t. the client object)  Entities can be separate (i.e. denote objects that are potentially separate w.r.t. to the client object)  Classes cannot be separate  If they were separate then w.r.t. what?  What would be the type of Current?  Proposal 1: prohibit separate classes  More about that in the talk on the type system

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Require target of separate call to be formal argument of enclosing routine: push_and_retrieve (s: separate STACK [INTEGER]; value: INTEGER) is -- 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  Body (do … end) of enclosing routine is a critical section with respect to its separate formal arguments. Locking in SCOOP No other processor can access s in the meantime

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Wait rule A routine call with separate arguments will execute when all corresponding objects are available and wait-conditions are satisfied and hold the objects exclusively for the duration of the routine A routine call with separate arguments will execute when all corresponding processors are available and wait-conditions are satisfied and hold the processors exclusively for the duration of the routine

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  What if we do not want to lock separate formal arguments? x: separate X set_x (an_x: separate X) is do x := an_x end r (an_x: separate X) is do an_x.f end (Too much) locking considered harmful No need to lock. Lock on necessary.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Only lock separate arguments that serve as target of separate call  Let compiler decide, based on routine body x: separate X set_x (an_x: separate X) is do x := an_x end r (an_x: separate X) is do an_x.f end Solution A: smart compiler Don’t lock. Lock.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Programmers are not as good at scanning the code as compilers  Implementation details might be hidden from the user  Polymorphism and dynamic binding mess up everything Solution A: discussion

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Explicit precondition (wait-condition) clause is_available (x)orx.is_available x: separate X set_x (an_x: separate X) is do x := an_x end r (an_x: separate X) is require is_available (an_x) do an_x.f end Solution B: preconditions No precondition. Don’t lock. Lock.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Theoretically beautiful  Support for polymorphism and dynamic binding  Less locking in redefined features through precondition weakening  Ugly in practice: too much burden on the programmer.  Who wants to write such code? r (x, y, z: separate X) is require is_available (x) is_available (y) is_available (z) x.is_empty do x.f z.g (y) end Solution B: discussion

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Separate arguments of attached type (X) are locked; detachable ones (?X) are not x: separate X set_x (an_x: separate ?X) is do x := an_x end r (an_x: separate X) is do an_x.f end Solution C: ? Detachable type. Don’t lock. Attached type. Lock.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop,  Support for polymorphism and dynamic binding  Less locking in redefined features through contravariant redefinition rule  Concise and practical: programmers are likely to accept it.  Proposal 2: retain this solution, i.e. Separate arguments of attached type (X) are locked; detachable ones (?X) are not Solution C: discussion

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, A problem … x.f x.g (y) … y.f Pc Px Py x.f x.g(y) y.f g (y: separate Y) is do y.fy.f … … … end y.f

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Lock passing  Former approach:  Make x wait until y becomes available  “Business Card principle” for dealing with some cases  Not flexible; many scenarios cannot be implemented  Proposal 3: lock passing  Let x get exclusive access on y immediately  “Pass the lock”  But: client that passes the lock has to wait  In fact, client can pass all its locks  You can still implement previous scenario

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Without lock passing r (x: separate X; y: separate Y) is do x.f x.g (y) -- x waits for y to become available. y.f … value := x.some_query -- Current waits for x. DEADLOCK. end s (x: separate X) is do z := x.g (Current) -- x waits for Current; Current waits for x. DEADLOCK. end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, With lock passing r (x: separate X; y: separate Y) is do x.f x.g (y)-- Current passes its locks to x -- and waits for x to finish g (y). y.f … value := x.some_query -- No deadlock occurs. end s (x: separate X) is do z := x.g (Current) -- Current passes its locks (including the lock on itself) to x. -- No deadlock occurs. end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Races  Beat enemy number one in concurrent world, i.e. data races  (traditional) Data race occurs when two or more threads concurrently access a shared variable, and at least one is writing.  (SCOOP) No data races can occur in SCOOP thanks to the sequential nature of processors.  Higher-level races (violations of mutual exclusion) might occur. They are caused by so-called traitors, i.e. non-separate entities that denote separate objects.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Traitors -- in class C (client) x: separate X a: A … r (an_x: separate X) is do a := an_x.a end … r (x) a.f -- supplier class X feature a: A end Is this call valid? And this one? TRAITOR!

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Consistency rules – first attempt  Four consistency rules  Should prevent races  eliminate traitors  Written in English  Easy to understand by programmers

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, SCOOP rules – first attempt Separateness consistency rule (1) If the source of an attachment (assignment instruction or argument passing) is separate, its target entity must be separate too. r (buffer: separate BUFFER [X]; x: X ) is local b1: separate BUFFER [X] b2: BUFFER [X] x2: separate X do b1 := buffer-- valid b2 := b1-- invalid r (b1, x2) -- invalid end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, SCOOP rules – first attempt Separateness consistency rule (2) If an actual argument of a separate call is of a reference type, the corresponding formal argument must be declared as separate. store (buffer: separate BUFFER [X]; x: X ) is do buffer.put (x) end -- in class BUFFER [G] put (element: separate G) is...

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, SCOOP rules – first attempt Separateness consistency rule (3) If the source of an attachment is the result of a separate call to a function returning a reference type, the target must be declared as separate. consume_element (buffer: separate BUFFER [X]) is local element: separate X do element := buffer.item... end -- in class BUFFER [G] item: G is...

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, SCOOP rules – first attempt Separateness consistency rule (4) If an actual argument of a separate call is of an expanded type, its base class may not include, directly or indirectly, any non-separate attribute of a reference type. store (buffer: separate BUFFER [X]; x: X ) is do buffer.put (x)-- X must be “fully expanded” end -- in class BUFFER [G] put (element: G) is-- G is not declared as separate anymore...

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Problem with expanded types x: X-- X is expanded, see below. consume_element (buffer: separate BUFFER [X]) is local s: STRING do x := buffer.item s := x.f.out-- Valid: call on expanded object. s := x.g.out-- Valid! call on separate reference. end expanded class X feature g: STRING f: INTEGER is... end traitor!!!

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Proposal 4: type system for SCOOP  Prevents races  static (compile-time) checks  Simplifies, refines and formalises SCOOP rules  Integrates expanded types and agents with SCOOP  Ownership-like types  Eiffel types augmented with owner tags  inspired by Peter Mueller’s work on applet isolation in JavaCard  Tool for reasoning about concurrent programs  can serve as basis for future extensions (e.g. for deadlock prevention)

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, A few definitions… Let TypeId denote the set of declared type identifiers of a given Eiffel program. We define the set of tagged types for a given class as where OwnerId is a set of owner tags (domains) declared in the given class. Each class implicitely declares two owner tags:  (current processor) and  (unknown). The subtype relation on tagged types is the smallest reflexive, transitive relation satisfying the following axioms, where  is a tag, S,T  TypeId, and denotes the subtype relation on TypeId:

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Specifying the type class C domain r1, r2 -- owner tags.  and  are declared implicitely. feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate Y within r1-- y :: (r1, Y) r (an_x: separate X) is-- an_x :: (, X) do a := an_x.a end …

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, And off we go! [Current]  Current :: (, T Current ) [DecNS] l: T    l :: ( , T) [DecSU] l: separate T    l :: (, T) [DecSO] l: separate T within r    l :: (r, T)

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Assignment Separateness consistency rule (1) If the source of an attachment (assignment instruction or argument passing) is separate, its target entity must be separate too.   l :: (, T),  e :: (, S), [Assign] (, S) (, T)  l := e

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Feature call  x :: (, T),  a :: (, S), (, S) (, T)*( fa, T fa ), [QCall]  ≠   xFormalArg,  =    fa =   x.f (a) :: (, T)*( fr, T fr ) FormalArg is the set of formal arguments of the routine where the expression is evaluated, ( fa,T fa ) is the type of the formal argument of feature f (we assume here that f has only one argument), ( fr, T fr ) is the type of its result. We also define the type combinator

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Type combinator     r2    r1  separate calls always return separate type non-separate calls preserve owner tag x :: (, T) f :: (, S) x.f :: (, S)

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, And now less formally  x :: (, T),  a :: (, S), (, S) (, T)*( fa, T fa ), [QCall]  ≠   xFormalArg,  =    fa =   x.f (a) :: (, T)*( fr, T fr ) x.f (a) FormalArg is the set of formal arguments of the routine where the expression is evaluated, ( fa,T fa ) is the type of the formal argument of feature f (we assume here that f has only one argument), ( fr, T fr ) is the type of its result. Separate Call rule consistency rules 1 and 2 together with [Assign] implies consistency rule 3

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Consistency rules – second attempt Attachment rule (0) The type of the source of an attachment (assignment instruction or argument passing) must conform to the type of its target. x :: (, T),y :: (, S) x := y valid iff (, S) (, T)  But this attachment rule that already exists in the type system!  The programmer just applies standard rule with augmented types.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Consistency rules – second attempt Expression type rule (1) Type of an expression (query call) x.f depends on the type of its target ( x :: (, T) ) and the declared type of the query ( f :: (, S) ). x.f :: (, T)*(, S)

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Consistency rules – second attempt Fully expanded types rule (2) An entity x that represents an object of a fully expanded type FT (i.e. whose base class does not include, directly or indirectly, any non-separate attribute of reference type) is seen as non-separate in any typing context. x :: ( , FT ) Basic types INTEGER, BOOLEAN, CHARACTER, REAL, etc. are fully expanded.

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: X -- a :: (, X) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) x := a -- valid because (, X) is a subtype of (, X) a := x -- invalid because (, X) is not a subtype of (, X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: X -- a :: (, X) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) x := y -- valid because (r1, X) is a subtype of (, X) y := x -- invalid because (, X) is not a subtype of (r1, X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: X -- a :: (, X) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) y := a -- invalid because ( , X) is not a subtype of (r1, X) a := y -- invalid because (r1, X) is not a subtype of ( , X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: X -- a :: (, X) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) -- assume that Z is a descendant of X y := z -- valid because (r1, Z) is a subtype of (r1, X) z := y -- invalid because (r1, X) is not a subtype of (r1, Z) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) r (an_x: separate X) is -- an_x :: (, X) do … end r (a) -- valid because (, X) is a subtype of (, X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) r (an_x: separate X) is -- an_x :: (, X) do … end r (x) -- valid because (, X) is a subtype of (, X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) r (an_x: separate X) is -- an_x :: (, X) do … end r (z) -- valid because (r1, Z) is a subtype of (, X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, X) s (an_x: X) is -- an_x :: (, X) do … end s (x) -- invalid because (, X) is not a subtype of ( , X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: attachment rule class X domain r1, r2 feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) z: separate Z within r1-- z :: (r1, Z) s (an_x: X) is -- an_x :: (, X) do … end s (a) -- valid because ( , X) is a subtype of ( , X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: expression type rule class X domain r1, r2 feature a: A -- a :: (, A) x: separate X -- x :: (, X) y: separate X within r1-- y :: (r1, X) r (an_x: separate X) is -- an_x :: (, X) do … end a := x.a -- invalid because (, A) is not a subtype of ( , A) x := y.x -- valid because (, X) is a subtype of (, X) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Examples: fully expanded types rule class X domain r1, r2 feature i: INTEGER -- i :: (, INTEGER) x: separate X -- x :: (, X) s (an_i: INTEGER) is -- an_i :: (, INTEGER) do … end s (i)-- obviously valid s (x.i) -- valid because x.i :: ( , INTEGER) x.s (i) -- valid end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Why do we need explicit owners? class X feature y: Y set_y (a_y: Y) is do y := a_y end -- in class C r (x: separate X) is local my_y: separate Y do my_y := x.y x.set_y (my_y) -- oops… -- set_y takes non-separate -- formal argument! end P1 o1 o2 P2 o7 x y my_y

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Proposal 5: domains  We need the possibility to say: Entities x1, x2, …, xn denote objects that are handled by the same processor. We say that x1, x2, …, xn belong to the same domain. class X feature y: Y set_y (a_y: Y) is do y := a_y end -- in class C domain r1 feature r (x: separate X  r1) is local my_y: separate Y  r1 do my_y := x.y x.set_y (my_y) -- it’s alright now! end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Another use of domains class X domain r1, r2 feature x: separate X -- x :: (, X) y, z: separate X within r1-- y :: (r1, X), -- z :: (r1, X) create x-- on which processor is x created? -- some fresh processor create y -- y is created on (a fresh) processor denoted by r1 create z -- z is created on processor denoted by r1 end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, False traitors brother friend brother friend brother friend processor 1 processor 2 Ueli Moritz Urs meet_someone_elses_friend (person: separate PERSON) is local a_friend: PERSON do a_friend := person.friend-- Invalid assignment. visit (a_friend) end

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, meet_someaone_elses_friend (person: separate PERSON) is local a_friend: PERSON do a_friend ?= person.friend-- Valid assignment attempt. if a_friend /= void then visit (a_friend) end end Handling false traitors brother friend brother friend brother friend processor 1 processor 2 Ueli Moritz Urs

Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, Proposal 6: semantics of assignment attempt instructionl ?= e with static types l :: (, T), e :: (, S) and dynamic type e :: ( d, S d ) is “equal” to: if ( d, S d ) (, T) then l  e else l  void end  Like in Eiffel but also downcasts owner tag  “deep downcast” over expanded attributes