SCOOP: an introduction

1. SCOOP: an introduction Bertrand Meyer Chair of Software Engineering, ETH Zurich, Switzerland http://se.inf.ethz.ch

2. 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!

3. The SCOOP model • Simple Concurrent Object-Oriented Programming • High-level concurrency mechanism • Fully uses inheritance and other O-O techniques • Applicable to many physical setups: multiprocessing, multithreading, distributed execution, Web services... • Based on Design by Contract and Eiffel concepts

4. Object-oriented computation Actions Objects Processor To perform a computation is • to use certain processors • to apply certain actions • to certain objects.

5. What makes an application concurrent? Processor: autonomous thread of control supporting sequential execution of instructions on one or more objects Can be implemented as: • Process • Thread • AppDomain (.NET) • Web service Actions Objects Processor

6. Feature call: synchronous x:CLASS_X ... x.f (a) Object 1 Object 2 f (a: A) require a /= Void ensure not a.empty previous_instruction . ( ) x f a next_instruction ( CLASS_T ) (CLASS_ X ) Processor

7. Separate feature call (asynchronous) x:separate CLASS_X ... x.f (a) Object 1 Object 2 f (a: A) require a /= Void ensure not a.empty previous_instruction . ( ) x f a next_instruction ( CLASS_T ) (CLASS_ X ) Processor 2 Processor 1

8. Access control policy Target of separate call must be formal argument of enclosing routine: store (buffer:separate BUFFER [INTEGER]; value: INTEGER)is -- Store value into buffer. do buffer.put (value) end Call with separate argument gives exclusive access: store (my_buffer, 10)

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

10. From preconditions to wait-conditions store (buffer:separate BUFFER [INTEGER]; value: INTEGER) is -- Store value into buffer. require not buffer.is_full value > 0 do buffer.put (value) ensure notbuffer.is_empty end ... store (my_buffer, 10) • If buffer is separate,. On separate target, precondition becomes wait condition

11. Wait by necessity • No special mechanism for client to resynchronize with supplier after separate call. • The client will wait only when it needs to: x.f x.g (a) y.f … value := x.some_query Wait here!

12. 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.

13. Duels

14. Mapping processors to physical resources Concurrency Control File (CCF) create system "lincoln" (4): "c:\prog\appl1\appl1.exe" "roosevelt" (2): "c:\prog\appl2\appl2.dll" "Current" (5): "c:\prog\appl3\appl3.dll" end external Database_handler: "jefferson" port 9000 ATM_handler: "gates" port 8001 end default port: 8001; instance: 10 end

15. SCOOP platform-independent .NET Compact Framework .NET POSIXThreads … Two-level architecture of SCOOP • Can be implemented on various platforms • Microsoft .NET is our reference platform

16. 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

17. X SEPARATE_ SUPPLIER SEPARATE_X SCOOPLI concepts • separate client • separate supplier Each separate client & separate supplier handled by different processor Class gets separateness through multiple inheritance:

18. SCOOPLI emulation of SCOOP concepts

19. SCOOPLI Architecture • SEPARATE_HANDLER: locking; checking wait conditions; scheduling of requests • PROCESSOR_HANDLERs: execute separate calls; implement processors

20. Example: Dining philosophers class PHILOSOPHERinherit PROCESS rename setupasgetup redefine step end feature {BUTLER} stepis do think ;eat (left, right) end eat (l, r: separate FORK)is -- Eat, having grabbed l and r. do… end end

21. Example: Bounded buffer usage Usage of bounded buffers buff: BUFFER_ACCESS [MESSAGE] my_buffer: BOUNDED_BUFFER [MESSAGE] createmy_buffer createbuff.make (my_buffer) buff.put (my_buffer, my_message) … buff.put (my_buffer, her_message) … my_query := buff.item (my_buffer)

22. Example: elevator Client Inheritance For maximal concurrency, all objects are separate

23. Dynamic diagram 1 CABIN_BUTTON ELEVATOR asynchronous call 4 2 synchronous call 3 GUI_MAIN_WINDOW ENGINE Scenario: Pressing the cabin button to move the elevator 1 Cabin button calls elevator.accept (target) 2 Elevator calls engine.move (floor) 3 Engine calls gui_main_window.move_elevator (cabin_number, floor) 4 Engine calls elevator.record_stop (position)

24. Class BUTTON separate class BUTTON feature target: INTEGER end

25. Class CABIN_BUTTON separate class CABIN_BUTTON inherit BUTTON feature cabin: ELEVATOR requestis -- Send to associated elevator a request to stop on leveltarget. do actual_request (cabin) end actual_request (e: ELEVATOR)is -- Get hold ofeand send a request to stop on leveltarget. do e.accept (target) end end

26. Class ELEVATOR separate class ELEVATOR feature {BUTTON, DISPATCHER} accept (floor: INTEGER)is -- Record and process a request to go tofloor. do record (floor) if notmovingthenprocess_requestend end feature {MOTOR} record_stop (floor: INTEGER)is -- Record information that elevator has stopped onfloor. do moving :=False ; position := floor ; process_request end

27. Class ELEVATOR feature {NONE} -- Implementation process_requestis -- Handle next pending request, if any. local floor: INTEGER do if notpending.is_empty then floor := pending.item ; actual_process (puller, floor) pending.remove end end actual_process (m: MOTOR; floor: INTEGER)is -- Handle next pending request, if any. do moving :=true ; m.move (floor) end feature {NONE}-- Implementation puller: MOTOR ; pending: QUEUE [INTEGER] end

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

29. Distributed execution • Processors (AppDomains) located on different machines • .NET takes care of the "dirty work" • Marshalling • Minimal cost of inter-AppDomain calls Computer1 Computer3 AppDomain1 o1.g AppDomain3 o1 o2 o4 o5 o4.f Computer2 AppDomain4 o8.g o9.f o6.f (o3) AppDomain2 o6 o7 o8 o3 o9

30. Conclusions • 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

31. Current work • Prevent deadlock • Statically checkable rules • Run-time deadlock avoidance • Extend access control policy • Multiple locking of separate objects • Extend for real-time • Duel mechanism with priorities • Timing assertions? • Integrate with Eiffel Software compiler • Direct support for processors in the CLI?