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 one new 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.

Object

Processor

Action

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: separate CLASS_X

11

Dual semantics of a call

Let x: separate CLASS_X

previous_instruction;

x.f (a);

next_instruction;

Object 1 Object 2

(CLASS_T) (CLASS_X)

Processor 1 Processor 2

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– create x.make (...)

assigns a new processor to handle that object

Obtain existing separate object through an external feature– server (name: STRING, ...): separate

DATABASE

14

A concurrency architecture

Process-based handle

Thread-based handle

CORBA-based handle

General concurrency mechanism (SCOOP)

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

SCOOP (General Concurrency Mechanism )

.NET Framework(Windows XP, Windows .NET Server, …)

.NET Compact Framework(Windows CE .NET, …)

Threads ...

16

Mapping the processors: the Concurrency Control File (CCF)

creationlocal_nodes:

system"pushkin" (2): "c:\system1\appllexe""akhmatova" (4): "/home/users/syst1"Current: "c:\system1\appl2lexe"

endremote_nodes:

system"lermontov": "c:\system1\appllexe""tiuchev" (2): "/usr/bin/syst2"

endendexternal

Ingres_handler: "mandelstam" port 9000ATM_handler: "pasternak" port 8001

enddefault

port: 8001; instance: 10end

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; ...): separate DATABASE

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.

O1 O2

x: X

y: separate Yx y

(Y)(X)

x.f(a)

x := y

X

Y

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 particular object at 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: separate SOME_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: separate SOME_TYPE

Instead of using attrib.r, we have to use rf (attrib, ...), where rf is:

rf  (x: separate SOME_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:if buffer.count >= 2 then

buffer.remove; buffer.removeend

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.

doif buffer.count >= 2 then

buffer.remove; buffer.removeend

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 stack

s.put (x1);

… other instructions;

s.put (x2);

… other instructions ;

value := s.item Wait here

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) isrequire

not b.fulldo

b.put (x)ensure

not b.emptyend

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

Challenger →

↓ Holder

normal_service immediate_service

retain Challenger waits Exception in challenger

yield Challenger waits Exception in holder; serve challenger

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

indexingdescription: “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.emptyend

36

Class BUFFER_ACCESS

remove (q: BOUNDED_BUFFER [G]) is-- Remove an element from q, waiting if necessary-- until there is such an element.

requirenot q.empty

doq.remove

ensurenot q.full

enditem (q: BOUNDED_BUFFER [G]): G is

-- Oldest element not yet consumedrequire

not q.emptydo

Result := q.itemensure

not q.fullend

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 ?