SCOOP – Eiffel Concurrency

Slides based on Object Oriented Software Construction 23-04-21 05:14 1Department of Computer Science, York University

SCOOP – Eiffel Concurrency

Slides adapted from Bertrand Meyer, ETH


Lecture 21:

Concurrency and real-time systems


Overview

Goal

Basics of the SCOOP model

Architecture and implementation of SCOOP

Examples

Basics of the real-time systems

Timing and real-time extensions

Conclusion and future work


Goal

Extend a pure, strongly typed, object-oriented language (Eiffel, …) with

a simple, general and powerful concurrency and distribution model ( SCOOP)

and extend SCOOP to support real-time programming


The SCOOP model

Simple Concurrent Object-Oriented Programming

High-level concurrency mechanism

Full use of inheritance and other object-oriented techniques

Applicable to many physical setups: multiprocessing, multithreading, distributed execution, etc.


Object-oriented computation

Object

Processor

Action

To perform a computation is to use certain processors to apply certain actions to certain objects.


What makes an application concurrent?

Processor:autonomous thread of control supporting sequential execution of instructions on one or more objects

Can be implemented as: Computer CPU Process Thread AppDomain (.NET) …

Mapping of processors to computational resourcesthrough Concurrency Control File (CCF)


Feature call (synchronous call)

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

x: CLASS_X

Object 1 Object 2

(CLASS_T) (CLASS_X)




x: CLASS_X

Object 1 Object 2

(CLASS_T) (CLASS_X)

previous_instruction

x.f (a)

next_instruction




x: CLASS_X

Object 1 Object 2

(CLASS_T) (CLASS_X)


x.f (a)

next_instruction




x: CLASS_X

f (a: A) is require a /= Void ensure not a.is_empty end

Object 1 Object 2

(CLASS_T) (CLASS_X)


x.f (a)

next_instruction




x: CLASS_X


Object 1 Object 2

(CLASS_T) (CLASS_X)


x.f (a)

next_instruction

Processor


Separate feature call (asynchronous call)


x: separate CLASS_X


Object 1 Object 2

(CLASS_T) (CLASS_X)


x.f (a)

next_instruction

Processor 1 Processor 2




x: CLASS_X


Object 1 Object 2

(CLASS_T) (CLASS_X)


x.f (a)

next_instruction

Processor


Separate feature call (asynchronous call)


x: separate CLASS_X


Object 1 Object 2

(CLASS_T) (CLASS_X)


x.f (a)

next_instruction

Processor 1 Processor 2


Access control policy

Target of a separate call must be formal argument of enclosing routine:

store (b: separate BUFFER [G]; value: G) is

-- Store value into b.do

b.put (value) end

To obtain exclusive access to a separate object, use it as argument of call:

my_buffer: separate BUFFER [INTEGER]

create my_buffer

store (my_buffer, 10)


From preconditions to wait-conditions

Contracts in Eiffelstore (b: BUFFER [G]; value: G) is

-- Store value into b. require

not b.is_fullvalue /= Void

dob.put (value)

ensurenot b.is_empty

end...store (my_buffer, 10)

If b is separate, precondition becomes wait condition (instead of correctness condition)


From preconditions to wait-conditions

Contracts in Eiffelstore (b: separate BUFFER [G]; value: G) is

-- Store value into b. require

not b.is_fullvalue /= Void

dob.put (value)

ensurenot b.is_empty

end...store (my_buffer, 10)

If b is separate, precondition becomes wait condition (instead of correctness condition)


Synchronization

No special mechanism needed for client to resynchronize with supplier after separate call.

The client will wait only when it needs to:x.fx.g (a)y.f…value := x.some_query


Synchronization


The client will wait only when it needs to:x.fx.g (a)y.f…value := x.some_query Wait here


Synchronization



… if value > 10 then … end

Wait here


Synchronization



… if value > 10 then … end

This mechanism is called wait by necessity.

Wait here


CCF – Mapping of processors to physical resources

Location of processors need not be specified at compile time

On the fly specification with Concurrency Control File (CCF)creation system "goethe" (4): "c:\prog\appl1\appl1.exe"

"beethoven" (2): "c:\prog\appl2\appl2.dll" "Current" (5): "c:\prog\appl3\appl3.dll" endexternal Database_handler: "daimler_benz" port 9000 ATM_handler: "duerer" port 8001enddefault port: 8001; instance: 10end


CCF – Mapping of processors to physical resources

Location of processors need not be specified at compile time

On the fly specification with Concurrency Control File (CCF)creation system "Current": "c:\prog\appl1\appl1.exe" end

end endexternal Database_handler: "daimler_benz" port 9000 ATM_handler: "duerer" port 8001enddefault port: 8001; instance: 10end


Two-level architecture of SCOOP

SCOOP can be implemented in several environments

Microsoft .NET is our current platform

SCOOPplatform-independent

.NET.NET

CompactFramework

POSIXThreads

…


Implementation

SCOOPLI for .NET and others Library implementation of SCOOP in its original

version Uses Remoting and Threading capabilities

of .NET Uses Threading capabilities of the .NET CF on

the RTOS Windows CE .NET (and/or other RTOS: VxWorks, etc.)


Example: Bounded buffers

separate class BOUNDED_BUFFER [G]inherit

BOUNDED_QUEUE [G]end



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.fulldo q.put (x)ensure not q.emptyend



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

item (q: BOUNDED_BUFFER [G]): G is -- Oldest element not yet consumedrequire not q.emptydo Result := q.removeend

end -- class BUFFER_ACCESS [G]



Usage of bounded buffers

my_buffer_access: BUFFER_ACCESS [INTEGER]my_bounded_buffer: BOUNDED_BUFFER [INTEGER]

create my_buffer_accesscreate my_bounded_buffer

my_buffer_access.put (my_bounded_buffer, 25)

my_buffer_access.put (my_bounded_buffer, 50)

my_result := my_buffer_acces.item (my_bounded_buffer)


Example: Dining philosophers

separate class PHILOSOPHER

inheritGENERAL_PHILOSOPHERPROCESS rename setup as getup undefine getup end

feature {BUTLER}

step is -- Perform a philosopher’s tasks.

do think eat (left, right)

end

eat (l, r: separate FORK) is -- Eat, having grabbed l and r.

do …

endend -- class PHILOSOPHER

The synchronization


Class PROCESS

indexingdescription: "The most general notion of process"

deferred class PROCESS

feature -- Status report

over: BOOLEAN is -- Must execution terminate now?

deferred end

feature -- Basic operations

setup is -- Prepare to execute process operations (default: nothing).

do end

step is -- Execute basic process operations.

deferred end


Class PROCESS (cont.)

wrapup is -- Execute termination operations (default: nothing).

do end

feature -- Process behavior

live is -- Perform process lifecycle.

do from setup until over loop step end wrapup

end

end -- class PROCESS


Class GENERAL_PHILOSOPHER

classGENERAL_PHILOSOPHER

createmake

feature -- Initialization

make (l, r: separate FORK) is-- Define l as left and r as right forks.

doleft := lright := r

end

feature {NONE} -- Implementation

left: separate FORK

right: separate FORK


Class GENERAL_PHILOSOPHER (cont.)

getup is -- Take any necessary initialization action.

do end

think is -- Any appropriate action or lack thereof

do end

end -- class GENERAL_PHILOSOPHER

classFORK

end


Class BUTLER

classBUTLER

createmake

featurecount: INTEGER

-- The number of both philosophers and forks

launch is-- Start a full session.

local i: INTEGER

do from

i := 1 until

i > count loop launch_one (participants @ i)

i := i + 1end

end


Class BUTLER (cont.)

feature -- {NONE}

launch_one (p: PHILOSOPHER) is-- Let one philosopher start his actual life.

dop.live

end

participants: ARRAY [PHILOSOPHER]

cutlery: ARRAY [FORK]

feature {NONE} -- Initialization

make (n: INTEGER) is-- Initialize a session with n philosophers.

requiren >= 0

docount := ncreate participants.make (1, count)create cutlery.make (1, count)make_philosopherslaunch

ensurecount = n

end


Class BUTLER (cont.)

make_philosophers is-- Set up philosophers.

locali: INTEGERp: PHILOSOPHERleft, right: separate FORK

dofrom i := 1until i > countloop left := cutlery @ i right := cutlery @ ((i \\ count) + 1) create p.make (left, right)

participants.put (p, i) i := i + 1end

end

invariantcount >= 0participants.count = countcutlery.count = count

end -- class BUTLER


Definition: Real-time system

Real-time system (Young, 1982):

Any information processing activity or system which has to respond to externally generated input stimuli within a finite and specified period.

The correctness of a real-time system depends not only on the logical result of the computation, but also on the time at which the results are produced ...

a correct but a late response is as bad as a wrong response ...


Hard and soft real-time systems

Hard real-time Systems where it is absolutely imperative that responses occur within the required deadline. E.g. flight control systems, …

Soft real-time Systems where deadlines are important but which will still function correctly if deadlines are occasionally missed.E.g. data acquisition system, …

A single real-time system may have both hard and soft real-time subsystems


Definition: Embedded system

Embedded system:

The computer is an information processing component within (embedded in) a larger engineering system.

(e.g. washing machine, process control computer, ABS ― Anti Blocking System in vehicles, ...)


Characteristics of real-time systems

Large and complex(up to 20 million lines of code estimated for the Space Station Freedom)

Concurrent control of separate system components

Facilities to interact with special purpose hardware

Extreme reliable and safe

Guaranteed response times


Components of a real-time system

Hardware (CPU, sensors, ADC, DAC, …)

Real-time OS (e.g VxWorks, QNX, Windows CE .NET, …)

Real-time application and real-time runtime system (e.g. Ada, Real-Time Java, C with Real-Time Posix and hopefully soon Real-Time SCOOP )


A simple embedded and real-time example

Screen

AD

C

AD

C

DA

C

Sw

itchT

S

P

Thermocouple

Heater

Pump/valve

Pressuretransducer

ADC = Analogue to digital converter

DAC = Digital to analogue converter

X separate object


A simple embedded and real-time example

Screen

AD

C

AD

C

DA

C

Sw

itchT

S

P

Thermocouple

Heater

Pump/valve

Pressuretransducer

ADC = Analogue to digital converter

DAC = Digital to analogue converter

X separate object

read every 200 ms

read every150 ms

response time:50 ms

response time:50 ms


Real-Time Facilities

Notion of time

Clocks

Delays

Timeouts

Temporal scopes


Notion of time

Linearity:

Transitivity:

Irreflexibility:

Density:

zxzyyxzyx )(:,,

)()()(:, yxxyyxyx

)(: xxnotx

)(::, yzxzyxyx

The passage of time is equated with a real line.


Access to a Clock

Direct access to the environment's time frame(e.g. transmitters for UTC = Universal Time Coordinated, UTC service of GPS)

Using an internal hardware clock that gives an adequate approximation to the passage of time in the environment


Clocks in Real-Time Java

java.lang.System.currentTimeMillis returns the number of milliseconds since 1/1/1970 GMT and is used by java.util.Date

Real-time Java adds real-time clocks with high resolution time types


RT Java Time Types (1)

public abstract class HighResolutionTime implements java.lang.Comparable{ public abstract AbsoluteTime absolute(Clock clock, AbsoluteTime destination);

...

public boolean equals(HighResolutionTime time); public final long getMilliseconds(); public final int getNanoseconds();

public void set(HighResolutionTime time); public void set(long millis); public void set(long millis, int nanos);}



public class AbsoluteTime extends HighResolutionTime{ // various constructor methods including public AbsoluteTime(AbsoluteTime T); public AbsoluteTime(long millis, int nanos);

public AbsoluteTime absolute(Clock clock, AbsoluteTime dest);

public AbsoluteTime add(long millis, int nanos); public final AbsoluteTime add(RelativeTime time);

...

public final RelativeTime subtract(AbsoluteTime time); public final AbsoluteTime subtract(RelativeTime time);

}



public class RelativeTime extends HighResolutionTime{ // various constructor methods including public RelativeTime(long millis, int nanos); public RelativeTime(RelativeTime time);

public AbsoluteTime absolute(Clock clock, AbsoluteTime destination);

public RelativeTime add(long millis, int nanos); public final RelativeTime add(RelativeTime time);

public void addInterarrivalTo(AbsoluteTime destination);

public final RelativeTime subtract(RelativeTime time); ...}public class RationalTime extends RelativeTime{ . . .}


RT Java: Clock Class

public abstract class Clock{ public Clock();

public static Clock getRealtimeClock();

public abstract RelativeTime getResolution();

public AbsoluteTime getTime(); public abstract void getTime(AbsoluteTime time);

public abstract void setResolution(RelativeTime resolution);

}


RT Java: Measuring Time

{ AbsoluteTime oldTime, newTime; RelativeTime interval; Clock clock = Clock.getRealtimeClock();

oldTime = clock.getTime(); // other computations newTime = clock.getTime();

interval = newTime.subtract(oldTime);

}


Delaying a Process (Thread)

The execution of a process (thread) must be sometimes delayed either for a relative period of time or until some time in the future

Relative delaysStart := Clock; -- from calendarloop exit when (Clock - Start) > 10.0;end loop;

Busy-waits are not efficient, therefore most languages and operating systems provide some form of delay primitive

In Ada, this is a delay statement

delay 10.0; In POSIX: sleep and nanosleep Java: sleep; RT Java provides a high resolution sleep


Delays

Time specified by program

Granularity difference between clock and delay

Interrupts disabled

Process runnable here but not executable

Process executing

Time


Absolute Delays

In AdaStart := Clock;First_action;delay 10.0 - (Clock - Start);Second_action;

Unfortunately, this might not achieve the desired result, therefore we use:Start := Clock;First_action;delay until Start + 10.0;Second_action;

As with delay, delay until is accurate only in its lower bound

RT Java - sleep can be relative or absolute POSIX requires use of an absolute timer and signal


Drifts

The time overrun associated with both relative and absolute delays is called the local drift and it cannot be eliminated

It is possible, however, to eliminate the cumulative drift that could arise if local drifts were allowed to superimpose


Periodic Activity

task body T is Interval : constant Duration := 5.0; Next_Time : Time;begin Next_Time := Clock + Interval; loop Action; delay until Next_Time; Next_Time := Next_Time + Interval; end loop;end T; Will run on average

every 5 seconds

local drift onlyIf Action takes 6 seconds, the delaystatement will have no effect


Control Example in Ada (1)

with Ada.Real_Time; use Ada.Real_Time;with Data_Types; use Data_Types;with IO; use IO;with Control_Procedures;use Control_Procedures;procedure Controller is

task Temp_Controller;

task Pressure_Controller;



task body Temp_Controller is TR : Temp_Reading; HS : Heater_Setting; Next : Time; Interval : Time_Span := Milliseconds(200); begin Next := Clock; -- start time loop Read(TR); Temp_Convert(TR,HS); Write(HS); Next := Next + Interval; delay until Next; end loop; end Temp_Controller;



task body Pressure_Controller is PR : Pressure_Reading; PS : Pressure_Setting; Next : Time; Interval : Time_Span := Milliseconds(150); begin Next := Clock; -- start time loop Read(PR); Pressure_Convert(PR,PS); Write(PS); Next := Next + Interval; delay until Next; end loop; end Pressure_Controller;begin null;end Controller;


Timeouts on Actions

select

delay 0.1;

then abort

-- action

end select;

If the action takes too long (more than 100 ms), the action will be aborted

Java supports timeouts through the class Timed.


Temporal Scopes (1)

Temporal scope: Collection of statements with an associated timing constraint

Deadline — the time by which the execution of a TS must be finished

Minimum delay — the minimum amount of time that must elapse before the start of execution of a TS

Maximum delay — the maximum amount of time that can elapse before the start of execution of a TS

Maximum execution time — of a TS Maximum elapse time — of a TS

Temporal scopes with combinations of these attributes are also possible


Temporal Scopes (2)Now

Time

Deadline

a

b

c

Minimum delayMaximum delay

Maximum elapse time

Units of executionMaximum execution time = a + b +c


Specifying Processes and TS

process periodic_P; ...begin loop IDLE start of temporal scope ... end of temporal scope end;end;

Time constraints: maximum and/or minimum times for IDLE At the end of the temporal scope a deadline must be met


Deadline

The deadline can itself be expressed in terms ofeither

absolute time

execution time since the start of the temporal scope, or

elapsed time since the start of the temporal scope.


Aperiodic Processes

process aperiodic_P; ...begin loop wait for interrupt start of temporal scope ... end of temporal scope end;end;


SCOOP for real-time systems

Timing assertions Maximal (and minimal) execution time Timeouts on actions Periodic and aperiodic activities

Possibility to execute the request of a VIP client while stopping the execution of the current client Duels Priorities


Timing in sequential programming

In library class TIMING_ASSERTION:

time_now: TIME-- The current time now.

min_time_duration: TIME_DURATION-- Minimal time duration of a feature

max_time_duration: TIME_DURATION-- Maximal time duration of a feature

In application class SUPPLIER (inherits TIMING_ASSERTION):

create min_time_duration.make_by_fine_seconds (1.0)create max_time_duration.make_by_fine_seconds (3.0)


Timing in sequential programming (cont.)

f (a_time_started: TIME; an_i: INTEGER): INTEGER isrequire

a_time_started_not_void: a_time_started /= Voidlocal

i: INTEGERdo

fromi := 0

untili = an_i

loopResult := Result + ii := i + 1

endcreate time_now.make_now

ensureminimal_execution_time: (time_now - a_time_started).duration >

min_time_duration

maximal_execution_time: (time_now - a_time_started).duration < max_time_duration

end



In client class CLIENT:

s: SUPPLIER time_now: TIME

res: INTEGER

create s create time_now.make_now res := s.f (time_now, 1000000)



f (a_time_started: TIME; an_i: INTEGER): INTEGER isrequire

a_time_started_not_void: a_time_started /= Voidlocal

i: INTEGERdo

fromi := 0

untili = an_i

loopResult := Result + ii := i + 1

endcreate time_now.make_now

ensureminimal_execution_time: (time_now - a_time_started).duration >

min_time_duration

maximal_execution_time: (time_now - a_time_started).duration < max_time_duration

end


Timing assertions

Specifying temporal scopes with the assertion mechanism ofEiffel (has consequences to the scheduling mechanism)

Maximal (and minimal?) execution time of a feature call x.f (a, b)

f (a: A, b: separate B) is require a /= Void not b.empty ensure

-- maximal execution time of f is 100 ms maximal_execution_time (100)

-- minimal execution time of f is 50 ms minimal_execution_time (50) end


Timing assertions

Timeout on actions

f (a: A, b: separate B) is require a /= Void not b.empty do

-- action b.g (h) must not take longer than 20 ms check timeout: timeout (20) b.g (h) end ensure

-- maximal execution time of f is 100 ms maximum_execution_time (100)

-- minimal execution time of f is 50 ms minimum_execution_time (50) end


Timing assertions

Specification of periodic (and aperiodic) activities

f (a: A, b: separate B) is require a /= Void not b.empty

-- activated at absolute time between 4000 and 4500 activation_time > 4000 and activation_time < 4500 ensure -- periodicity is 500 ms periodicity (500)

end


Duels

Can we snatch a shared object from its current holder?

holder executesholder.r (b) where b is separate

Then another object challenger executeschallenger.s (c) where c, also separate, is

attached to the same object as the holder‘s b

Normally, the challenger will wait until the call to r is over.

What if the challenger is impatient?


Duels

Use library features from class CONCURRENCY: 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


Extending duels with priorities

Tuning the duel mechanism:

holder.set_priority (50)

challenger.set_priority (100)

holder.yield

challenger.immediate_service

If the priority of the challenger is bigger than the priority of theholder (challenger.priority > holder.priority):

holder will get an exception challenger will be served.


Conclusion

SCOOP model is simple yet powerful Full concurrency Full use of object-oriented techniques One keyword separate Based on Design by Contract™ Several platforms and architectures

(multiprocessing, multithreading, distributed execution, etc).


Future work

Extension of access control policy multiple locking of separate objects based on

the concept of pure functions Instruction-level parallelism Deadlock prevention Extending SCOOP for real-time systems

adding priorities to the duel mechanism specifying temporal scopes with the assertion

mechanism SCOOP can be used for persistence

with the STORABLE class mechanism and separate DATABASE


References

http://se.inf.ethz.ch/people/nienaltowski

http://se.inf.ethz.ch/people/arslan

http://se.inf.ethz.ch/projects (Concurrency, distribution, ...)

Nienaltowski P., Arslan V., Meyer B.: SCOOP: Concurrent Programming Made Easy, in process of submission

Simon D., An Embedded Software Primer, 3rd printing, Addison-Wesley, 2000

Burns A., Wellings A., Real-Time Systems and Programming Languages, 3rd edition, Addison-Wesley, 2001


End of lecture 21


Lecture 25:

Concurrent O-O principles


The goal

Provide a practical and general foundation for concurrent and distributed programming, ensuring reliability, reusability availability and extendibility.


The issue

Everyone wants to benefit from concurrency and distribution Physical (networks, multiprocessors) Logical (processors, threads)

but applications remain extremely difficult to build, especially to build right.

SCOOP provides: Generality Ease of programming Robustness (including liveness, ...) Availability Extendibility, reusability


Generality

Provide a simple, general, easy to use concurrency and distribution mechanism for programming concurrent applications:

Internet and Web programming. Web services, peer-to-peer... Client-server applications. Distributed processing. Multi-threading. Multiple processes (Unix, Windows 95, Windows

NT).


An example: Multithreading

Increasingly popular Notoriously hard to get right; major mistakes

remain in released applications; theoretical pitfalls Impedance mismatch with O-O programming

concepts Synchronization often achieved by low-level

mechanisms

“Almaviva”name

landlord

loved_one

O1

“Figaro”O2

“Susanna”

O3


Concurrency and objects

“I can’t understand why objects [of O-O languages]are not concurrent in the first place”.

Robin Milner, 1991


Formulating the question

What is the simplest extension of object technology that will support all forms of concurrent computation — in an elegant, general and efficient way?


Basic O-O mechanism

Feature call (message passing):

x.f (a)


Concurrent O-O should be easy!

(But: it’s not!)

Analogies between objects/classes and processes/process-types:

General decentralized structure, independent modules.

Encapsulated behavior (a single cycle for a process; any number of routines for a class).

Local variables (attributes of a class, variables of a process or process type).

Persistent data, keeping its value between successive activations.


But the analogy breaks down quickly…

... and leaves room to apparent incompatibilities:

Classes are repositories of services; it is fundamental that they should be able to support more than one.

How will processes serve each other’s requests?

The "inheritance anomaly"


Capturing common behaviors

deferred class PROCESS

feature

live is-- General structure with variants.

dofrom

setupuntil

overloop

stependfinalize

end

feature {NONE}

setup is deferred end

over: BOOLEAN is deferred end

step is deferred end

finalize is deferred end

end

Why limit ourselves to just one behavior when we can have as many as we want?


A printer mechanism

class PRINTER

inherit

PROCESSrename

over as off_line,finalize as stop

end

feature

stop is-- Go off-line.

dooff_line := True

end

step is-- Execute individual actions of an iteration step.

dostart_jobprocess_jobfinish_job

end


A printer mechanism (cont’d)

feature {NONE}

setup isdo

…end

start_job isdo

…end

process_job isdo

…end

finish_job isdo

…end

end


Other possible features

print_diagnostics

prepare_for_maintenance

restart_job


The basic triangle of computation

Computing consists of applying operations to objects; to do so requires the appropriate mechanisms – processors.

Action Object

Processor


Separate entities

A call of the form x.f (a) has different semantics when handled by the same or different processors.

Need to declare whether client processor is the same as supplier processor or another.

x: separate A

Contrast with the usual

x: A

which guarantees handling by same processor.


Consistency rule

In assignment

x := y

If the source y is separate, the target x must be separate too.

Same rule for argument passing.


Separate entities and classes

b: separate BOUNDED_QUEUE [SOME_TYPE]

or:

separate class BOUNDED_BUFFER [G]

inherit

BOUNDED_QUEUE [G]

end

x: BOUNDED_BUFFER [SOME_TYPE]


Creation

If x is separate, then the creation instruction

create x

grabs a new processor, physical or virtual, and assigns it to handle the object.

Also: it is possible to obtain a separate object as the result of a function. So processors can be allocated outside of Eiffel text proper.


Generality

“Separate” declaration does not specify the processor.

Semantic difference between sequential and concurrent computation narrowed down to difference for separate calls:

Precondition semantics Argument passing semantics Creation semantics.


Two-level architecture

General-purpose top layer (SCOOP). Several architecture-specific variants at the bottom

layer (SCOOP handles).

Initial handles: .NET remoting; POSIX threads;

SCOOP

HANDLE nHANDLE 1 HANDLE 2



SCOOP

….NET THREADS


Predefined constructs and libraries

Define specific details (how many processors...) and scheduling policies through libraries.


Processor assignment

The assignment of actual physical resources to (virtual) processors) is entirely dynamic and external to the software text.

Simple notation: Concurrency Control File (CCF)

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.


End of lecture 25


Lecture 26:

Concurrent O-O principles


class BOUNDED_QUEUE [G]

feature

put (x: G) is-- Add x to queue.

requirenot is_full

do…

ensurenot is_empty

end

remove: G is-- Delete oldest element from queue.

requirenot is_empty

do…

ensurenot is_full

end

Design by Contract


The contract model (cont’d)

invariant

maxcount = capacity – 10 <= oldestoldest <= capacity0 <= nextnext <= capacityabs (next – oldest) < capacity

end

1oldest

capacity

maxcount

next


The contract of a feature

Client

Supplier

(Satisfy precondition:)

Make sure queue not full.

(Satisfy postcondition:)

Insert x, making sure queue is not empty.

Obligations

(From postcondition:)

Make queue not empty, x added.

(From precondition:)

Simpler processing thanks to assumption that queue not full.

Benefits


The correctness of a class

(1-n) For every exported routine r:

{INV and prer} dor {INV and postr}

(1-m) For every creation procedure cp:

{precp} docp {postcp and INV}

a.f (…)

a.g (…)

a.f (…)

create a.make (…)S1

S2

S3

S4


Express messages?

An express message is a message that must be treated right away, interrupting any current routine call. But: how do we preserve the consistency of

objects (invariants)?

The model will support a restricted form of express messages, which does not conflict with provability.

Unit of granularity for mutual exclusion is routine call.

But: can be interrupted, causing an exception.


Provability

Proof rule for routines:

{ INV p } Body (r) { INV q }

p Pre (r) q Post (r)

{ p’ } Call (r) { q’ }


In other words: to prove the validity of all calls, it suffices to prove (once!) the correctness of the body.


What becomes of the contract model?

q: BOUNDED_QUEUE [X]a: X...if not q.is_full then

q.put (a)end

Or:

q.removeq.put (x)

But: this does not work for separate threads of control!

What do preconditions now mean?


Reserving an object

q: separate BOUNDED_QUEUE [X]a: X...a := q.item

... Other instructions (not calling remove) ...q.remove

How do we guarantee that item and remove apply to the same buffer element?

Proposed answer: Just use encapsulation. Argument passing serves as reservation. If object busy (processor not available), block object; processor will service other object if possible.


Reserving an object (cont’d)

class BUFFER_ACCESS [X]

feature

put (q: separate BOUNDED_QUEUE [G]; x: G) is-- Insert x into q, waiting if necessary-- until there is room.

requirenot q.is_full

doq.put (x)

ensurenot q.is_empty

end


Reserving an object (cont’d)

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

requirenot q.is_empty

doq.remove

ensurenot q.is_full

end

item (q: separate BOUNDED_QUEUE [G]): G is-- Oldest element not yet consumed

... Left to reader ...

end


Semantic rules

With the class as shown on the previous pages, the call

put (q)

will block until: q is available. The precondition not q.is_full is true.

The new rule only affects: Separate arguments. Precondition clauses which include calls on

separate targets (i.e. x.f with x separate).


The original proof rule

{ INV p } Body (r) { INV q }


{ p’ } Call (r) { q’ }



The new proof rule

{ INV p } Body (r) { INV q }p Nonsep_Pre (r) q Nonsep_Post (r)

{ p’ } Call (r) { q’ } p Nonsep_Pre (r) q Nonsep_Post (r)

Nonsep_pre (r): set of clauses in r’s precondition which do not involve any separate calls.

Similarly for Nonsep_post (r).


Wait by necessity

r (...; t: separate SOME_TYPE; ...) is do

...t.f (...)other_instructions

end

When do we wait?


Wait by necessity (cont’d)

For example:

r (...; t: separate SOME_TYPE; ...) is do

...t.p (...)other_instruction_1...other_instruction_nk := t.some_value

end

Wait on queries (calls to attributes and functions), not procedure calls.

WAIT HERE


Blocking semantics is not always appropriate

f: FILE

...

if f /= Void and then f.readable thenf.some_input_routine

-- some_input_routine is any routine-- that reads data from the file; -- its precondition is readable.

end


Duels

Request immediate service: immediate_service

Accept immediate service: yield

Exception in challenger

Exception in holder; serve challenger.

Challenger waits

Challenger waits

normal_service immediate_service

insist

yield

Challenger

Holder


Dining philosophers


Dining philosophers (cont’d)

separate class PHILOSOPHER

inherit PROCESS

rename setup as getup

end

create

make

feature {BUTLER}step is

dothinkeat (left, right)

end


Dining philosophers (cont’d)

feature {NONE}

left, right: separate FORK-- The two required forks

getup is-- Take any necessary initialization action.

do ...

endthink is

-- Any appropriate action.do

... end

eat (l, r: separate FORK) is-- Eat, having grabbed l and r.

do ...

end

end


A binary tree class, non-parallel

class BINARY_TREE [G]

feature

left, right: BINARY_TREE [G]

nodes: INTEGER is-- Number of nodes in this tree

doResult := node_count (left) + node_count (right) + 1

end

feature {NONE}

node_count (b: BINARY_TREE [G]): INTEGER is-- Number of nodes in b

doif b /= Void then

Result := b.nodesend

end

end


A binary tree class: Parallel version

separate class BINARY_TREE [G]

feature

left, right: BINARY_TREE [G]

… Other features …

nodes: INTEGER

update_nodes is-- Update nodes to reflect number of nodes in this-- tree.

donodes := 1compute_nodes (left)compute_nodes (right)adjust_nodes (left)adjust_nodes (right)

end


Parallel version (cont’d)

feature {NONE}

compute_nodes (b: BINARY_TREE [G]) is-- Update information about the number of nodes in

b.do

if b /= Void thenb.update_nodes

endend

adjust_nodes (b: BINARY_TREE [G]) is-- Adjust number of nodes from those in b.

doif b /= Void then

nodes := nodes + b.nodesend

end

end


Other examples in OOSC-2

Coroutines Locking a resource — semaphores An elevator control system A watchdog mechanism (execute an action, but

take control back if not done after t seconds)



SCOOP

….NET THREADS


.NET remoting library

Provides a good basis for SCOOP:

AppDomains: Partition object set Marshal by Value, Marshal by Reference All types are potentially remotable Threading library


AppDomains

“Almaviva”name

landlord

loved_one

O1

“Figaro”O2

“Susanna”

O3

Context

Context

AppDomain AppDomainProcess


Challenges

Conceptual: Systematic approach to deadlock prevention Precise fairness policies Proof rules, actual proofs.

Organizational: Language & compiler integration

But also an opportunity Building industrial-grade software in a university

But: ETH CS tradition; Dept and university support


End of lecture 26

Documents

SCOOP – Eiffel Concurrency