scoop on.net volkan arslan chair of software engineering eth zurich, switzerland email:...
Post on 14-Dec-2015
219 Views
Preview:
TRANSCRIPT
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 ?
top related