SCOOP on .NET

1. SCOOP on .NET Volkan Arslan Chair of Software Engineering ETH Zurich, Switzerland Email: Volkan.Arslan@inf.ethz.ch

2. SCOOP mechanism • SCOOP stands forSimple Concurrent Object Oriented Programming • Goal of SCOOP:Extend a pure, strongly typed, object-oriented language (Eiffel) with a general and powerful concurrency and distribution model.

3. SCOOP goals • Minimality of mechanism (only onenew keyword) • Full use of inheritance and other object-oriented techniques • Compatibility with Design By Contract • Provability • Support for command-query distinction • Adaptability through libraries • Support for reuse of non-concurrent software • Support for deadlock avoidance • Applicability to many forms of concurrency

4. Concurrency variants SCOOP covers different concurrency variants • Multiprocessing • Client-server computing • Multitasking, multiprogramming • Intra-application concurrency (concurrency within one application) • Object Request Brokers (ORB) • Remote execution (e.g. through the WWW) • (Hard) real-time and embedded systems

5. Basic new mechanism for OO technology Question: What should be the basic language mechanism for supporting concurrent object oriented programming ?

6. Object Oriented computation • To perform a computation is • to use certain processors • to apply certain actions • to certain objects.

7. Processor • Definition: Processoran autonomous thread of control capable of supporting the sequential execution of instructions on one or more objects • Processors should be not confused with physical devices (e.g. a CPU). Processor is an abstract notion, the number of processors are therefore not bounded. • Processors can be implemented with: • a computer (with its CPU) on a network • a task or process as supported on OS such as Unix, Windows and others • a thread • a coroutine

8. Processor (cont.) • Processors are the basic new mechanism for concurrent object oriented programming • Mapping of computational resources to the processors are done by a CCF („Concurrency Control File“)

9. Handling an object • A feature call like x.f(a) must be handled (executed) by some processor • More generally any object is handled by a certain processor, its handler. • An handler is assigned to the object at the time of creation, and remains same throughout the objects‘ life. • Nevertheless, object migration is possible through • reassignment of a processor to a different CPU • treating object migration as the creation of a new object

10. Separate Entities A call of the form x.f (a) has different semantics when handled by the same or different processors. We need to declare in our source code whether a client processor is the same as a supplier processor or another. x: separateCLASS_X

11. Dual semantics of a call • Let x: separateCLASS_X

12. Dual semantics of a call (cont.) Dual semantics of a call: • If Object 1 and Object 2 have the same processor, any further operation on Object 1 (next_instruction) must wait until the call terminates. Such calls are said to be synchronous. • If Object 1 and Object 2 are handled by different processors, operation on Object 1 can proceed as soon as it has initiated the call on Object 2. Such calls are said to be asynchronous.

13. Obtaining separate objects • Separate creation • createx.make (...)assigns a new processor to handle that object • Obtain existing separate object through an external feature • server (name: STRING, ...): separate DATABASE

14. General concurrency mechanism ( SCOOP ) Process-based Thread-based CORBA- handle handle based handle A concurrency architecture Two-level architecture: • First layer: platform-independent • Second layer: platform-dependent

15. A concurrency architecture (cont.) Two-level architecture: • First layer: platform-independent • Second layer: platform-dependent

16. Mapping the processors: the Concurrency Control File (CCF) creation local_nodes: system "pushkin" (2): "c:\system1\appllexe" "akhmatova" (4): "/home/users/syst1" Current: "c:\system1\appl2lexe" end remote_nodes: system "lermontov": "c:\system1\appllexe" "tiuchev" (2): "/usr/bin/syst2" end end external Ingres_handler: "mandelstam" port 9000 ATM_handler: "pasternak" port 8001 end default port: 8001; instance: 10 end

17. Concurrency Control File (CCF) • Creation part specifies what CPUs to use for separate creations: • e.g. set_cpu_nodes („local_nodes“) from class CONCURRENCY • in this example all processors are mapped to processes, but they can be mapped to threads or to other concurrency mechanisms • External part specifies where to look for existing external separate objects: • server (name: STRING; ...): separateDATABASE

18. Validity rule Separateness consistency rule If the source of an attachment (assignment instruction or argument passing) is separate, its target entity must be separate too.

19. Traitor The call x.f(a) would wrongly be understood by the compiler as synchronous, whereas the attached object O2 is in fact separate and requires asynchronous processing. Such a reference is called a traitor.

20. Concurrent accesses to an object • How many executions may proceed concurrently on an object ? • For simplicity and consistency and especially in order to reason on our classes at most one routine can execute on any particularobjectat any particular time. • In a case of emergency, or if a client keeps an object for too long, it is possible to interrupt the client (triggering an exception) →duels

21. Reserving an object • To reserve a separate object, you simply use it as actual argument in a call: actions_requiring_exclusive_access (a) This causes the caller to wait until the object, to which a is attached, is available

22. Reserving an object (cont.) r (a:separateSOME_TYPE) is do ; a.r1 ();  ; a.r2 ();  end most separate calls do not need to wait

23. Accessing separate objects Separate Call rule The target of a separate call must be a formal argument of the routine in which the call appears.

24. Accessing separate objects (cont.) • Let attrib: separateSOME_TYPE • Instead of using attrib.r, we have to use rf (attrib, ...), where rf is: rf  (x:separateSOME_TYPE; ) is -- Call r on x. do x.r () end

25. Accessing separate objects (cont.) Advantage of the Separate Call rule is: • Encourages developers to identify accesses to separate objects and separate them from the rest of the computation.

26. Accessing separate objects (cont.) • Avoids critical errors that would be almost bound to happen without it • Example:ifbuffer.count >= 2 then buffer.remove; buffer.remove end The above example will not always work, unless we have secured exclussive access to buffer

27. Accessing separate objects (cont.) Solution: remove_two (buffer: BOUNDED_BUFFER)is -- Remove oldest two items. do if buffer.count >= 2 then buffer.remove; buffer.remove end end where BOUNDED_BUFFER is separate

28. Wait by necessity • Wait by necessity:Once a separate call has started, a client only needs to wait for its termination if the call is to a query (calls to functions and attributes). • Example: s is a separate stacks.put (x1); … other instructions; s.put (x2); … other instructions ; value := s.item

29. Synchronization • Basic synchronization mechanism: actions_requiring_exclusive_access (a) causes the caller to wait until the object attached to a is available

30. Synchronization (cont.) • Sometimes you do not want to grab an object unconditionally, but only when a certain condition becomes true • Now we have two different semantics of preconditions: a precondition applying to a separate argument will be a wait condition instead of a correctness condition

31. Separate precondition put (b: BOUNDED_BUFFER [T]; x: T)is require not b.full do b.put(x) ensure not b.empty end where BOUNDED_BUFFER [T] is separate The call put (q, a_value) will block until: • q is available. • the precondition not q.full is true.

32. Duels • Duel:the attempt to snatch a shared object from its current holder • But we cannot simply stop the current client, execute the request of the VIP client, and then resume the original client: We would, in most cases, end up with an inconsistent object.

33. Duels (cont.) • Request immediate service:immediate_service • Accept immediate service: yield

34. Example: Bounded buffers separate class BOUNDED_BUFFER [G] inherit BOUNDED_QUEUE [G] end • To use a call such as q.remove (where e.g. q: BOUNDED_BUFFER [INTEGER]), you must enclose it in a routine using q as formal argument. • Therefore it may be useful to provide a class BUFFER_ACCESS that fully encapsulates the notion of bounded buffer

35. Class BUFFER_ACCESS indexing description: “Encapsulation of access to bounded buffers class BUFFER_ACCESS [G] feature put (q: BOUNDED_BUFFER [G]; x: G)is -- Insert x into q, waiting if necessary until there is -- room. require not q.full do q.put (x) ensure not q.empty end

36. Class BUFFER_ACCESS remove(q: BOUNDED_BUFFER [G])is -- Remove an element from q, waiting if necessary -- until there is such an element. require not q.empty do q.remove ensure not q.full end item(q: BOUNDED_BUFFER [G]): G is -- Oldest element not yet consumed require not q.empty do Result:= q.item ensure not q.full end end

37. Challenges Conceptual: • Systematic approach to deadlock prevention • Precise fairness policies • Proof rules, actual proofs Technical: • Implementation of SCOOP on .NET using the .NET Remoting and Threading library

38. Questions ?