Transcript No Slide Title

Concurrent Object-Oriented Programming
SCOOP
Volkan Arslan, Bertrand Meyer, Piotr Nienaltowski
Chair of Software Engineering, ETH Zurich, Switzerland
Goal
Example: Bounded Buffers
Method
Processors
SCOOP: Simple Concurrent Object-Oriented
Programming
Reserving an object
Action
Object
Extend the pure, strongly typed, object-oriented
language Eiffel with a general and powerful concurrency
and distribution model.
Processor
SCOOP goals:
To perform a computation is
• Minimality of mechanism (only one new keyword)

• Full use of inheritance and other object-oriented
techniques
to use certain processors
 to apply certain actions
 to certain objects.
• Compatibility with Design By Contract
• Provability
Definition: processor
• Support for command-query distinction
A processor is an autonomous thread of control capable
of supporting the sequential execution of instructions on
one or more objects.
• Applicability to many forms of concurrency
• Adaptability through libraries
• Support for reuse of non-concurrent software
Separate Entities
• Support for deadlock avoidance
Need to declare whether client processor is the same as
supplier processor or another.
x: separate CLASS_X
Concurrency variants
Object 1
• Multiprocessing
• Client server computing
• Multitasking, multiprogramming
• Intra-application concurrency (concurrency within an
application)
• Object Request Brokers (ORB)
• Remote execution (e.g. through the WWW)
• (Hard) real-time and embedded systems
Object 2
previous_instruction;
x.f (a);
next_instruction;
(CLASS_T)
(CLASS_X)
Processor 1
Processor 2
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.
SCOOP architecture
SCOOP (General Concurrency Mechanism )
.NET Framework
(Windows XP, Windows .NET Server, …)
.NET Compact Framework
(Windows CE .NET, …)
Two-level architecture:
• First layer:
Platform independent
• Second layer: Platform dependent
Threads
...
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.
class BUFFER_ACCESS [G]
feature
put (q: separate BOUNDED_QUEUE [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
end
The call put (q, a_value) will block until:
• q is available.
• the precondition not q.full is true.
A precondition applying to a separate argument will be a
wait condition instead of a correctness condition.
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.
r (..., t: separate SOME_TYPE, ...) is
do
t.p (...)
other_instruction
Wait here
k := t.some_value
end
Duels
separate class BOUNDED_BUFFER [G]
inherit
BOUNDED_QUEUE [G]
end
• To use a call such as
q.remove (where q: BOUNDED_BUFFER [G]), you
must enclose it in a routine using q as formal argument.
• It may be useful to provide a class BUFFER_ACCESS
that fully encapsulates the notion of bounded buffer.
indexing
description: “Encapsulation of access to bounded buffers"
class BUFFER_ACCESS [G]
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
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 -- BUFFER_ACCESS [G]
Processor assignment
Simple notation: Concurrency Control File (CCF)
The attempt to snatch a shared object from its current
holder.
Request immediate service: immediate_service
Accept immediate service: yield
Challenger → normal_service
↓ Holder
immediate_service
retain
Challenger waits
Exception in challenger
yield
Challenger waits
Exception in holder;
serve challenger
creation
proc1: sales.microsoft.com (2),
coffees.whitehouse.gov (5), ...
proc2: 89.9.200.151 (1), ...
Physical resources may be Internet nodes, threads, Unix
or Windows processes, etc.
Challenges
• Systematic approach to deadlock prevention
• Precise fairness policies
• Proof rules, actual proofs