1. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 1 SCOOPLI for.NET: a library for concurrent object-oriented programming Volkan Arslan, Piotr Nienaltowski Chair of Software Engineering, ETH Zurich

2. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 2 Overview  Motivation  The SCOOP model for concurrent OO programming  SCOOPLI library  Implementation for.NET  Conclusions

3. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 3 Motivation Extend a pure, strongly typed, object-oriented language with a simple, general and powerful concurrency and distribution model

4. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 4 The SCOOP model  Simple Concurrent Object-Oriented Programming  High-level concurrency mechanism  Full use of inheritance and other object-oriented techniques (genericity, agents, …)  Applicable to many physical setups: multiprocessing, multithreading, distributed execution, etc.  Minimal extension of Eiffel  one new keyword separate  Based on Design by Contract™  new semantics for preconditions

5. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 5 Two-level implementation of SCOOP  SCOOP can be implemented in several environments  Microsoft.NET is our reference platform SCOOP platform-independent.NET Compact Framework POSIX…

6. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 6 Asynchronous calls  Fundamental scheme of the O-O computation: feature call x.f (a)  Caller and callee handled by different processors  Asynchronous semantics

7. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 7 Processors  Processor is an autonomous thread of control capable of supporting the sequential execution of instructions on one or more objects  Principal new concept introduced by SCOOP  Not to be confused with a physical CPU! It can be implemented as:  piece of hardware (computer, CPU),  process,  thread,  AppDomain,  etc.

8. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 8 Access control policy  Target of a separate call must be a formal argument of the enclosing routine store (buffer: separate BUFFER; value: INTEGER) is -- Store value in buffer. do buffer.put (value) end... buf: separate BUFFER create buf.make store (buf, 10) -- instead of buf.put (10)  In order to obtain exclusive access to a separate object, use the attached entity as an argument of the corresponding call, as in store (buf, 10).

9. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 9 From preconditions to wait-conditions  Contracts in Eiffel store (buffer: BUFFER; value: INTEGER) is -- Store value in buffer. require buffer_not_full: not buffer.is_full do buffer.put (value) ensure buffer_not_empty: not buffer.is_empty end... store (buf, 10)  If buffer is separate, correctness condition buffer_not_full becomes wait condition

10. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 10 Synchronization  No special mechanism is required for a client to resynchronize with its supplier after a separate call.  The client will wait if and only if it needs: x.f x.g (a) y.f... value := x.some_query  This mechanism is called wait by necessity.

11. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 11 SCOOPLI library  The library relies on two concepts:  separate client  separate supplier  Separate client is handled by a different processor than each of its separate suppliers.  SCOOPLI uses multiple inheritance to provide separateness: SEPARATE_ SUPPLIER X SEPARATE_X

12. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 12 Use of SCOOPLI (1/2) 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) is require not x.is_empty y.count > 5 i > 0 -- i non-separate do... end separate_execute ([x, y], agent r (x, y), agent r_precondition) r_precondition: BOOLEAN is do Result := not x.is_empty and y.count > 5 end -- separate_execute defined in -- class SEPARATE_CLIENT -- client class inherits from -- class SEPARATE_CLIENT

13. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 13 Feature separate_execute of SEPARATE_CLIENT separate_execute (requested_objects: TUPLE [SEPARATE_SUPPLIER]; action: PROCEDURE [ANY, TUPLE]; wait_condition: FUNCTION [ANY, TUPLE, BOOLEAN]) Formal arguments:  requested_objects Denotes the (tuple of) objects on which exclusive locks should be acquired before calling action.  action Denotes the routine to be called on the separate client object; action corresponds to the routine that “wraps” separate calls  wait_condition Denotes the boolean function representing the wait condition for the call

14. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 14 Use of SCOOPLI (1/2) 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) is require not x.is_empty y.count > 5 i > 0 -- i non-separate do... end separate_execute ([x, y], agent r (x, y), agent r_precondition) r_precondition: BOOLEAN is do Result := not x.is_empty and y.count > 5 end -- separate_execute defined in -- class SEPARATE_CLIENT -- client class inherits from -- class SEPARATE_CLIENT

15. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 15 Use of SCOOPLI (2/2) SCOOPSCOOPLI x.f (a) -- a is expandedseparate_routine (x, agent x.f (a)) res := x.g (a) -- g is function and returns -- reference value -- res is non-separate res ?= separate_value (x, agent x.g (a)) i := x.h (a) -- h is function and returns -- expanded value -- res is non-separate i := separate_integer_value (x, agent x.h (a)) -- use function corresponding to returned type: -- boolean_value, integer_value, real_value, -- double_value, char_value if x.count > 0 then...if separate_integer_value (x, agent x.g (a)) > 0 then...

16. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 16 Feature separate_routine of SEPARATE_CLIENT separate_routine (supplier: SEPARATE_SUPPLIER; procedure: PROCEDURE [ANY, TUPLE]) Formal arguments:  supplier Denotes the separate supplier object on which the separate call to procedure is made  procedure Denotes the routine to be called on the separate supplier object

17. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 17 Use of SCOOPLI (2/2) SCOOPSCOOPLI x.f (a) -- a is expandedseparate_routine (x, agent x.f (a)) res := x.g (a) -- g is function and returns -- reference value -- res is non-separate res ?= separate_value (x, agent x.g (a)) i := x.h (a) -- h is function and returns -- expanded value -- res is non-separate i := separate_integer_value (x, agent x.h (a)) -- use function corresponding to returned type: -- boolean_value, integer_value, real_value, -- double_value, char_value if x.count > 0 then...if separate_integer_value (x, agent x.g (a)) > 0 then...

18. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 18 Feature separate_value of SEPARATE_CLIENT separate_value (supplier: SEPARATE_SUPPLIER; function: FUNCTION [ANY, TUPLE, ANY]): ANY Formal arguments:  Supplier Denotes the separate supplier object on which the separate call to function is made.  Function Denotes the function to be evaluated. Return value is of type ANY

19. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 19 Use of SCOOPLI (2/2) SCOOPSCOOPLI x.f (a) -- a is expandedseparate_routine (x, agent x.f (a)) res := x.g (a) -- g is function and returns -- reference value -- res is non-separate res ?= separate_value (x, agent x.g (a)) i := x.h (a) -- h is function and returns -- expanded value -- res is non-separate i := separate_integer_value (x, agent x.h (a)) -- use function corresponding to returned type: -- boolean_value, integer_value, real_value, -- double_value, char_value if x.count > 0 then...if separate_integer_value (x, agent x.count) > 0 then...

20. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 20 SCOOPLI for.NET  Mapping of SCOOP concepts to.NET constructs  Processors  AppDomains  Namespace System.Runtime.Remoting  Use of multithreading  Single feature calls on separate objects, thus one thread per AppDomain  Namespace System.Threading  ThreadPool

21. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 21 Distributed execution  Processors (AppDomains) located on different machines .NET takes care of the “dirty work”  Marshalling  Minimal cost of inter-AppDomain calls Computer1 AppDomain1 o1 o2 Computer2 AppDomain2 o3 o9 Computer3 AppDomain3 o4 o5 AppDomain4 o6 o7 o8 o9.f o1.g o6.f(o3) o8.g o4.f

22. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 22 CCF – Concurrency Control File  Location of processors does not need to be specified at compile time  On-the-fly specification with CCF creation local_nodes: system "susi" (1): "c:\prog\appl1\appl1.exe" "ruth" (1): "c:\prog\appl2\appl2.dll" "schlemmer" (2): "c:\prog\appl3\appl3.dll" end

23. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 23 Conclusions  SCOOP model is simple yet powerful  Full concurrency  Full use of object-oriented techniques  One keyword separate  Based on Design by Contract™  Several platforms  SCOOPLI library  SCOOP-based syntax  Separate clients, separate suppliers .NET as reference platform  Processors mapped to AppDomains  Distributed execution with.NET Remoting

24. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 24 Future research  Extension of access control policy  multiple locking of separate objects based on the concept of pure functions  SCOOP for real-time systems  specifying timing constraints  adding priorities to the duel mechanism  Implementation  Use of agents and delegates  Porting of SCOOPLI to.NET CF using threads

25. 2 nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003 25 Questions ? Thank you !