scoopli for .net : a library for concurrent object-oriented programming

2nd Microsoft Rotor Workshop, Pisa, April 23-25, 2003

1

SCOOPLI for .NET:a library for concurrent

object-oriented programmingVolkan Arslan, Piotr NienaltowskiChair of Software Engineering, ETH Zurich


2Overview

Motivation

The SCOOP model for concurrent OO programming

SCOOPLI library

Implementation for .NET

Conclusions


3Motivation

Extend a pure, strongly typed, object-oriented language with a simple, general and powerful concurrency and distribution model


4The 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


5Two-level implementation of SCOOP

SCOOP can be implemented in several environments

Microsoft .NET is our reference platform

SCOOPplatform-independent

.NET.NET

CompactFramework

POSIX …


6Asynchronous calls

Fundamental scheme of the O-O computation: feature call x.f (a)

Caller and callee handled by different processors Asynchronous semantics

previous_instruction;

x.f (a);

next_instruction;

Object 1 Object 2

(CLASS_T) (CLASS_X)

Processor 1 Processor 2


7Processors

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.


8Access control policy

Target of a separate call must be a formal argument of the enclosing routinestore (buffer: separate BUFFER; value: INTEGER) is

-- Store value in buffer. do

buffer.put (value) end...buf: separate BUFFERcreate buf.makestore (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).


9From preconditions to wait-conditions

Contracts in Eiffelstore (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


10Synchronization

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.fx.g (a)y.f...value := x.some_query

This mechanism is called wait by necessity.

Wait here


11SCOOPLI 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


12Use of SCOOPLI (1/2)

SCOOP SCOOPLI

x: separate Xx: 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


13Feature 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.

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



SCOOP SCOOPLI

x: separate Xx: 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



SCOOP SCOOPLI

x.f (a) -- a is expanded separate_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 ...


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

procedureDenotes the routine to be called on the separate supplier object



SCOOP SCOOPLI






if x.count > 0 then ... if separate_integer_value (x, agent x.g (a)) > 0 then ...


18Feature 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.

FunctionDenotes the function to be evaluated.

Return value is of type ANY



SCOOP SCOOPLI






if x.count > 0 then ... if separate_integer_value (x, agent x.count) > 0 then ...


20SCOOPLI 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


21Distributed 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


22CCF – Concurrency Control File

Location of processors does not need to be specified at compile time

On-the-fly specification with CCFcreationlocal_nodes: system "susi" (1): "c:\prog\appl1\appl1.exe"

"ruth" (1): "c:\prog\appl2\appl2.dll" "schlemmer" (2): "c:\prog\appl3\appl3.dll" end


23Conclusions

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


24Future 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


25Questions ?

Thank you !

scoopli for .net : a library for concurrent object-oriented programming

Documents