1 / 25

SCOOPLI for .NET : a library for concurrent object-oriented programming

SCOOPLI for .NET : a library for concurrent object-oriented programming. Volkan Arslan, Piotr Nienaltowski Chair of Software Engineering, ETH Zurich. Overview. Motivation The SCOOP model for concurrent OO programming SCOOPLI library Implementation for .NET Conclusions. Motivation.

zalika
Download Presentation

SCOOPLI for .NET : a library for concurrent object-oriented programming

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. Overview • Motivation • The SCOOP model for concurrent OO programming • SCOOPLI library • Implementation for .NET • Conclusions 2nd 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 2nd 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 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  5. SCOOP platform-independent .NET Compact Framework .NET POSIX … Two-level implementation of SCOOP • SCOOP can be implemented in several environments • Microsoft .NET is our reference platform 2nd 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 2nd 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. 2nd 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). 2nd 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 2nd 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. 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  11. X SEPARATE_ SUPPLIER SEPARATE_X 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: 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  12. Use of SCOOPLI (1/2) 2nd 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_objectsDenotes the (tuple of) objects on which exclusive locks should be acquired before calling action. • actionDenotes the routine to be called on the separate client object; action corresponds to the routine that “wraps” separate calls • wait_conditionDenotes the boolean function representing the wait condition for the call 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  14. Use of SCOOPLI (1/2) 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  15. Use of SCOOPLI (2/2) 2nd 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: • supplierDenotes the separate supplier object on which the separate call to procedure is made • procedureDenotes the routine to be called on the separate supplier object 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  17. Use of SCOOPLI (2/2) 2nd 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: • SupplierDenotes the separate supplier object on which the separate call to function is made. • FunctionDenotes the function to be evaluated. Return value is of type ANY 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

  19. Use of SCOOPLI (2/2) 2nd 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 2nd 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 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 2nd 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 2nd 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 keywordseparate • 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 2nd 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 2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

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

More Related