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

2. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 2 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

3. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 3 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.

4. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 4 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

5. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 5 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?

6. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 6 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

7. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 7 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

8. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 8 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

9. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 9  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

10. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 10 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

11. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 11  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.

12. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 12  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.

13. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 13  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

14. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 14  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.

15. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 15  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

16. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 16  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.

17. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 17  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

18. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 18 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

19. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 19 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

20. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 20 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

21. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 21 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

22. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 22 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.

23. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 23 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!

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

25. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 25 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

26. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 26 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...

27. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 27 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...

28. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 28 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...

29. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 29 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!!!

30. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 30 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)

31. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 31 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:

32. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 32 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 …

33. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 33 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)

34. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 34 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

35. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 35 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

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

37. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 37 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

38. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 38 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.

39. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 39 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)

40. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 40 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.

41. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 41 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

42. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 42 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

43. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 43 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

44. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 44 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

45. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 45 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

46. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 46 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

47. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 47 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

48. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 48 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

49. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 49 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

50. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 50 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

51. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 51 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

52. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 52 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

53. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 53 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

54. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 54 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

55. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 55 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

56. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 56 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

57. Chair of Software EngineeringPiotr Nienaltowski, 2 nd SCOOP workshop, 05.07.2005 57 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