1. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 1 SCOOP Simple Concurrent Object-Oriented Programming

2. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 2 Lecture 2 (8): Validity rules, type system

3. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 3 Outline  Refresher on Lecture 1  Problem of traitors  Validity rules – first attempt  Some formal stuff (yeah!)  Type system for SCOOP  Validity rules – second attempt  Handling false traitors  Resources  Examples

4. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 4 Summary: computational model  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

5. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 5 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

6. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 6 Summary: synchronisation  Mutual exclusion  Locking through argument passing  Routine body is critical section  Condition synchronisation  wait-conditions  Re-synchronisation of client and supplier:  wait-by-necessity  Lock passing through argument passing

7. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 7 Summary: separate argument rule The target of a separate call must be a formal argument of the enclosing routine Separate call: a.f (...) where a is a separate entity

8. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 8 Summary: 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

9. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 9 What SCOOP should do for us  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) Data race occurs when two or more clients concurrently apply some feature on the same supplier.  Data races could be caused by so-called traitors, i.e. non-separate entities that denote separate objects.  Kill ’em all!

10. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 10 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!

11. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 11 Consistency rules – first attempt  Four consistency rules  Should prevent data races  eliminate traitors  Written in English  Easy to understand by programmers

12. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 12 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

13. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 13 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...

14. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 14 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...

15. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 15 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...

16. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 16 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!!!

17. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 17 Missing rule? Separateness consistency rule (5) If the source of an attachment is the result of a separate call to a function returning an expanded type, the class that defines this type may not include, directly or indirectly, any non-separate attribute of a reference type.  Handling of expanded objects still unsatisfactory  Many useful programs ruled out  Is it the only missing rule?

18. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 18 Is that the right solution?  SCOOP rules  prevent data races (almost), +  written in English, easy to understand by humans, +  cannot be directly used by compilers, -  not sound, too restrictive, -  no support for agents. -  How to do it better?  Refine and formalise the rules!

19. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 19 The question for today How do you know whether assignment x := y -- x and y are declared as -- x: CLASS_X; y: CLASS_Y and argument passing r (x) -- r is declared as r (an_x: SOME_CLASS) are valid?

20. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 20 Type system for SCOOP  Prevents data races  static (compile-time) checks  Simplifies, refines and formalises SCOOP rules  Integrates expanded types and agents with SCOOP  More about it in Lecture 4  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)

21. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 21 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 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:

22. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 22 And off we go! [Current]  Current :: (current_processor, T Current ) [DecNS] l  Dom ()  l: T :: (current_processor, T) [DecSU] l  Dom ()  l: separate T :: (unknown, T) [DecSO] l  Dom ()  l: separate T within r :: (r, T)

23. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 23 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

24. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 24 Feature call  x :: (, T),  a :: (, S), (, S) (, T)*( fa, T fa ), [QCall]  ≠ current_processor  xFormalArg  x.f (a) :: (, T)*( fr, T fr ) FormArg 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

25. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 25 Type combinator   current_ processor unknownr2 current_ processor current_ processor unknownr2 unknown r1 unknown separate calls always return separate type non-separate calls preserve owner tag

26. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 26 And now less formally  x :: (, T),  a :: (, S), (, S) (, T)*( fa, T fa ), [QCall]  ≠ current_processor  xFormalArg  x.f (a) :: (, T)*( fr, T fr ) x.f (a) FormArg 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

27. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 27 Consistency rules – second attempt Attachment rule The source of an attachment (assignment instruction or argument passing) must conform to its target. x :: (, T),y :: (, S) x := y valid iff (, S) (, T)  But this is exactly the attachment rule that already exists in the type system!  The programmer just applies standard rule

28. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 28 Consistency rules – second attempt Basic types rule An entity x that represents an object of a basic type BT (such as BOOLEAN, INTEGER, CHAR, etc. based on a fully expanded class) is seen as non-separate in any typing context .  x :: (current_processor, BT) Expression type rule Type of an expression (query call) depends on the type of its target ( x :: (, T) ) and the declared type of the query ( f :: (, S) ). x.f :: (, T)*(, S)

29. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 29 False traitors spouse friend spouse friend spouse friend processor 1 processor 2 wife hubby Urs meet_friend (person: separate PERSON) is local a_friend: PERSON do a_friend := person.friend-- Invalid assignment. visit (a_friend) end

30. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 30 meet_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 spouse friend spouse friend spouse friend processor 1 processor 2 wife hubby Urs

31. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 31 Assignment attempt  Like in Eiffel but also downcasts unknown to current_processor  “deep downcast” over expanded attributes  l :: (, T),  e :: (, S) [AssignAtt]  l ?= e   current_ processor unknown current_ processor like Eiffel + downcast unknownlike Eiffel

32. Chair of Software Engineering Piotr Nienaltowski, 17.05.2005 32 That’s all, folks! Questions?