1. Chair of Software Engineering SCOOP for ROTOR Bertrand Meyer Capstone (ROTOR final workshop), 2005 © Bertrand Meyer, 2005

2. Chair of Software Engineering 2 store (b : [G ] ; v : G ) -- Store v into b. require not b. is_full do … ensure not b. is_empty end QUEUEBUFFER my_queue : [T ] … if not my_queue. is_full then store (my_queue, t ) end BUFFER QUEUE

3. Chair of Software Engineering 3 Basic goal Can we bring concurrent programming to the same level of abstraction and convenience as sequential programming?

4. Chair of Software Engineering 4 The world is not just sequential any more Multithreading Internet-based applications Distribution Pervasive computing Web services (Coroutines…) Everyone says they’re doing it. Many Those who are doing it are not doing it very well! are actually doing itFew

5. Chair of Software Engineering 5 Previous advances Structured programming, object technology:  Higher level of abstraction  Removes bugs  Removes restrictions  Adds restrictions  Does things for you  There is a mathematical basis  You don’t need to know it to benefit

6. Chair of Software Engineering 6 Then and now Sequential programming: Used to be messy Still hard but:  Structured programming  Data abstraction & object technology  Design by Contract  Genericity, multiple inheritance  Architectural techniques Switch from operational reasoning to logical deduction (e.g. invariants) Concurrent programming: Used to be messy Still messy Example: threading models in most popular approaches Development level: ca. 1968 Only understandable through operational reasoning

7. Chair of Software Engineering 7 Dining philosophers class PHILOSOPHER inherit PROCESS rename setup as getup redefine step end feature {BUTLER} step do think ; eat (left, right) end eat (l, r: separate FORK) -- Eat, having grabbed l and r. do … end end

8. Chair of Software Engineering 8 This mechanism SCOOP: Simple Concurrent Object-Oriented Programming First iteration 1990 CACM, 1993 Object-Oriented Software Construction, 2 nd edition, 1997 Prototype implementations, 1995-now No being done for good at ETH On top of Eiffel Software’s compiler for.NET (Classic, ENVISION)

9. Chair of Software Engineering 9 Can object technology help? “Objects are naturally concurrent” (Milner) Many attempts, often based on (self-contradictory) notion of “Active objects” Often lead to “Inheritance anomaly” None widely accepted In practice: low-level mechanisms on top of O-O language

10. Chair of Software Engineering 10 Object-oriented computation To perform a computation is  To apply certain actions  To certain objects  Using certain processors Processor Actions Objects

11. Chair of Software Engineering 11 What makes an application concurrent? Processor: Thread of control supporting sequential execution of instructions on one or more objects Can be implemented as:  Computer CPU  Process  Thread  AppDomain (.NET) … Will be mapped to computational resources Processor Actions Objects

12. Chair of Software Engineering 12 Handling rule All calls on an object are executed by the processor’s handler

13. Chair of Software Engineering 13 Reasoning about objects {Pre r and INV} body r {Post r and INV } ___________________________________ {Pre r ’} x.r (a) {Post r ’}

14. Chair of Software Engineering 14 Reasoning about objects Only n proofs if n exported routines! {Pre r and INV} body r {Post r and INV } ___________________________________ {Pre r ’} x.r (a) {Post r ’}

15. Chair of Software Engineering 15 In a concurrent context Only n proofs if n exported routines? {Pre r and INV} body r {Post r and INV } ___________________________________ {Pre r ’} x.r (a) {Post r ’} Client 1, r1Client 2, r2 Client 3, r3

16. Chair of Software Engineering 16 Mutual exclusion rule At most one feature may execute on any one object at any one time

17. Chair of Software Engineering 17 Feature call: sequential x: CX x. r (a) Processor r (a:A) require a /=Void ensure not a. is_empty end Client Supplier ( CX ) previous_instruction x. r ( a ) next_instruction

18. Chair of Software Engineering 18 Feature call: asynchronous x: separate CX x. r (a) Client Supplier ( CX ) Client processorSupplier processor previous_instruction x. r ( a ) next_instruction r (a:A) require a /=Void ensure not a.is_empty end

19. Chair of Software Engineering 19 Separateness rule Calls on non-separate objects are blocking Call on separate objects are non-blocking

20. Chair of Software Engineering 20 Feature call: asynchronous x: separate CX x. r (a) Client Supplier ( CX ) Client processorSupplier processor previous_instruction x. r ( a ) next_instruction r (a:A) require a /=Void ensure not a.is_empty end

21. Chair of Software Engineering 21 The fundamental difference To wait or not to wait: If same processor, synchronous If different processor, asynchronous Difference must be captured by syntax:  x: CX  x: separate CX

22. Chair of Software Engineering 22 Consistency Supplier: class B feature p (a: separate SOME_TYPE) do... end end Client: class C feature a: SOME_TYPE sep: separate B sep.p (a) end

23. Chair of Software Engineering 23 Consistency Supplier: class B feature p (a: separate SOME_TYPE) do... end end Client: class C feature a: SOME_TYPE sep: separate B sep.p (a) end separate

24. Chair of Software Engineering 24 Separateness consistency rule For any reference actual argument in a separate call, the corresponding formal argument must be declared as separate Separate call: a.f (...) where a is separate

25. Chair of Software Engineering 25 If no access control x: separate STACK [T] … my_stack.push (a) y := my_stack.top

26. Chair of Software Engineering 26 Access control policy Require target of separate call to be formal argument of enclosing routine: put (b: separate STACK [T]; value: T) -- Push value on top of b. do b.push (value) end

27. Chair of Software Engineering 27 Access control policy Target of a separate call must be formal argument of enclosing routine: store (b : separate BUFFER [T]; value : T) -- Store value into b. do b.put (value) end To use separate object: my_buffer: separate BUFFER [INTEGER] create my_buffer store (my_buffer, 10)

28. Chair of Software Engineering 28 Separate argument rule The target of a separate call must be an argument of the enclosing routine Separate call: a.f (...) where a is separate

29. Chair of Software Engineering 29 Wait rule A routine call with separate arguments will execute when all corresponding objects are available and hold them exclusively for the duration of the routine Separate call: a.f (...) where a is separate

30. Chair of Software Engineering 30 Contracts in Eiffel store (buffer: BUFFER [INTEGER]; value: INTEGER) -- Store value into buffer. require not buffer.is_full value > 0 do buffer.put (value) ensure not buffer.is_empty end... store (my_buffer, 10) If b is separate, precondition becomes wait condition (instead of correctness condition) Precondition

31. Chair of Software Engineering 31 From preconditions to wait-conditions store (b : separate BUFFER [T ] ; v : T) -- Store v into b. require not b. is_full v > 0 do b. put (v) ensure not b. is_empty end... store (my_buffer, t ) If buffer is separate,. On separate target, precondition becomes wait condition

32. Chair of Software Engineering 32 Separate precondition rule A separate precondition causes the client to wait Separate precondition: a.condition (...) where a is separate

33. Chair of Software Engineering 33 Full synchronization rule A call with separate arguments waits until:  The corresponding objects are all available  Separate preconditions hold x.f (a) where a is separate

34. Chair of Software Engineering 34 Resynchronization No special mechanism needed for client to resynchronize with supplier after separate call. The client will wait only when it needs to: x.fx.f x.g (a) y.fy.f … value := x.some_query Wait here!

35. Chair of Software Engineering 35 Resynchronization rule Clients wait for resynchronization on queries

36. Chair of Software Engineering 36 Duels Problem: Impatient client (challenger) wants to snatch object from another client (holder) Can’t just interrupt holder, service challenger, and resume holder: would produce inconsistent object. But: can cause exception, which will be handled safely.

37. Chair of Software Engineering 37 Duels Library features Challenger → ↓ Holder normal_serviceimmediate_service retain Challenger waits Exception in challenger yield Challenger waits Exception in holder; serve challenger

38. Chair of Software Engineering 38 Two-level architecture of SCOOP Adaptable to many environments.NET is current platform SCOOP platform-independent.NET Remoting. NET Compact Framework …

39. Chair of Software Engineering 39 SCOOPLI: Library for SCOOP Library-based solution Implemented in Eiffel for.NET (from Eiffel Software: EiffelStudio / ENViSioN! for Visual Studio.NET) Aim: try out solutions without bothering with compiler issues Can serve as a basis for compiler implementations

40. Chair of Software Engineering 40 SCOOPLI emulation of SCOOP concepts SCOOPSCOOPLI x: separate X x: X -- class X is separate x: SEPARATE_X -- SEPARATE_X inherits from X and -- SEPARATE_SUPPLIER r (x, y) -- x and y are separate r (x: separate X; y: separate Y) require not x.is_empty y.count > 5 i > 0 -- i non-separate x /= Void do... end separate_execute ([x, y], agent r (x, y), agent r_precondition) r_precondition: BOOLEAN do Result := not x.is_empty and y.count > 5 end -- client class inherits from -- class SEPARATE_CLIENT

41. Chair of Software Engineering 41 SCOOPLI Architecture SEPARATE_HANDLER: locking; checking wait conditions; scheduling of requests PROCESSOR_HANDLERs: execute separate calls; implement processors Inheritance Client

42. Chair of Software Engineering 42 SCOOP multithreaded elevators

43. Chair of Software Engineering 43 Elevator example architecture For maximal concurrency, all objects are separate Inheritance Client

44. Chair of Software Engineering 44 Class BUTTON separate class BUTTON feature target: INTEGER end

45. Chair of Software Engineering 45 Class CABIN_BUTTON separate class CABIN_BUTTON inherit BUTTON feature cabin: ELEVATOR request -- Send to associated elevator a request to stop on level target. do actual_request (cabin) end actual_request (e: ELEVATOR) -- Get hold of e and send a request to stop on level target. do e.accept (target) end

46. Chair of Software Engineering 46 Class ELEVATOR separate class ELEVATOR feature {BUTTON, DISPATCHER} accept (floor: INTEGER) -- Record and process a request to go to floor. do record (floor) if not moving then process_request end end feature {MOTOR} record_stop (floor: INTEGER) -- Record information that elevator has stopped on floor. do moving := False ; position := floor ; process_request end

47. Chair of Software Engineering 47 Class ELEVATOR feature {NONE} -- Implementation process_request -- Handle next pending request, if any. local floor: INTEGER do if not pending.is_empty then floor := pending.item ; actual_process (puller, floor) pending.remove end actual_process (m: MOTOR; floor: INTEGER) -- Handle next pending request, if any. do moving := true ; m.move (floor) end feature {NONE} -- Implementation puller: MOTOR ; pending: QUEUE [INTEGER] end

48. Chair of Software Engineering 48 Class MOTOR separate class MOTOR feature {ELEVATOR} move (floor: INTEGER) -- Go to floor; once there, report. do gui_main_window.move_elevator (cabin_number, floor) signal_stopped (cabin) end signal_stopped (e: ELEVATOR) -- Report that elevator e stopped on level position. do e.record_stop (position) end feature {NONE} cabin: ELEVATOR ; position: INTEGER -- Current floor level. gui_main_window: GUI_MAIN_WINDOW end

49. Chair of Software Engineering 49 Why SCOOP? SCOOP model  Simple yet powerful  Easier and safer than common concurrent techniques, e.g. Java Threads  Full concurrency support  Full use O-O and Design by Contract  Supports various platforms and concurrency architectures  One new keyword: separate SCOOPLI library  SCOOP-based syntax  Implemented on.NET  Distributed execution with.NET Remoting

50. Chair of Software Engineering 50 Why SCOOP? Extend object technology with general and powerful concurrency support Provide the industry with simple techniques for parallel, distributed, internet, real-time programming Make programmers sleep better!

51. Chair of Software Engineering 51 Status  All of SCOOP except duels implemented, on top of.NET  Preprocessor and library available for download; current version is 3.2000  Numerous examples available for download se.ethz.ch/research/scoop.html We are grateful to MSR/Rotor for funding (also Hasler Foundation and Swiss National Science Foundation)

52. Chair of Software Engineering 52 Future work & open problems Type system Distribution and Web Services Deadlock prevention and detection Wait on first of several events Compact framework Extend for real-time  Duel mechanism with priorities  Timing assertions? Integrate with compiler se.ethz.ch/research/scoop.html se.ethz.ch/touch