Chair of Software Engineering OOSC Lecture 20 - Concurrency Object-Oriented Software Construction...

OOSC Lecture 20 - ConcurrencyChair of Software Engineering

Object-Oriented Software Construction

Bertrand Meyer


Lecture 20:

Object-oriented concurrency

Piotr Nienaltowski


Overview

A bit of history

O-O and concurrency

SCOOP model

Examples


Sequential programming

Used to be messy

It is still hard but: Structured programming Data abstraction & object technology Design by Contract Genericity Architectural techniques

Switch from operational reasoning to logical deduction (e.g. invariants)


Concurrent programming

Used to be messy

And it still is! Java/C# threading models No real breakthrough

Only understandable through operational reasoning


Impedance mismatch

OO: high-level abstraction mechanisms

Concurrency: very low-level mechanisms semaphores, locks, critical sections, suspend, …


O-O and concurrency

“I don’t understand why objects are non concurrent in the first place” (Robin Milner)

Many attempts, e.g. active objects

Problems: inheritance anomaly

No mechanism widely accepted

In practice, low-level mechanisms on top of O-O language


Motivations

Extend object technology with general and powerful concurrency support

Provide the industry with simple techniques for parallel, distributed, Internet, real-time programming

Let programmers sleep better!


The SCOOP model

Simple Concurrent Object-Oriented Programming

High-level concurrency mechanism

Fully uses inheritance and other O-O techniques

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

Minimal extension of Eiffel

Based on Design by Contract


Object-oriented computation

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

Processor

Actions 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: Process Thread

current implementation based on .NET threading

AppDomain (.NET) Web service

Processor

Actions Objects


Handling rule

All calls on an object are executed by its processor’s handler


Feature call: synchronous

x: CLASS_X...x.f (a)

Object 1 Object 2

(CLASS_T ) (CLASS_X)

previous_instruction

x . f (a)next_instruction

Processor

f (a: A) require a /= Void ensure not a.empty


Separate feature call: asynchronous

x: separate CLASS_X...x.f (a)

(CLASS_T) (CLASS_X)

Processor 1 Processor 2

Object 1 Object 2

previous_instruction

x . f (a)next_instruction

f (a: A) require a /= Void ensure not a.empty


Separateness rule

Calls to non-separate objects are synchronous

Calls to separate objects are asynchronous


Reasoning about objects

{Prer and INV} bodyr {POSTr and INV}

{Prer’} x.r (a) {POSTr’}

Only n proofs for n exported routines!


In a concurrent context

{Prer and INV} bodyr {POSTr and INV}

{Prer’} x.r (a) {POSTr’}

Only n proofs for n exported routines?

Client 3, r3

Client 2, r2

Client 1, r1


Mutual exclusion rule

At most one feature may execute on any one object at any one time


Access control policy

Target of separate call must be formal argument of enclosing routine: store (buffer: separate BUFFER [INTEGER]; value: INTEGER) is

-- Store value into buffer. do

buffer.put (value) end

Call with separate argument gives exclusive access: store (my_buffer, 10)


Contracts in Eiffel

store (buffer: BUFFER [INTEGER]; value: INTEGER) is

-- Store value into buffer. require

not buffer.is_fullvalue > 0

dobuffer.put (value)

ensurenot buffer.is_empty

end...store (my_buffer, 10)

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

Precondition


From preconditions to wait-conditions

store (buffer: separate BUFFER [INTEGER]; value: INTEGER) is

-- Store value into buffer. require

not buffer.is_fullvalue > 0

dobuffer.put (value)

ensurenot buffer.is_empty

end...store (my_buffer, 10)

On separate target, precondition becomes wait condition


Wait by necessity

No special mechanism 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

Wait here!


Duels

Problem: Impatient client (challenger) wants to snatch object from another client (holder)

Can’t just interrupt holder, service challenger, and resume holder: would produce inconsistent object.

But: can cause exception, which will be handled safely.


Challenger →

↓ Holder

normal_service immediate_service

retain Challenger waits Exception in challenger

yield Challenger waits Exception in holder; serve challenger

Duels


Mapping processors to physical resources

Concurrency Control File (CCF)

create system

"palin" (4): "c:\prog\appl1\appl1.exe" "cleese" (2): "c:\prog\appl2\appl2.dll"

"Current" (5): "c:\prog\appl3\appl3.dll" endexternal Database_handler: "jones" port 9000 ATM_handler: "chapman" port 8001enddefault port: 8001; instance: 10end


Implementation of SCOOP

Can be implemented on various platforms Microsoft .NET is our reference platform

SCOOPplatform-independent

.NET / ROTOR

.NETCompact

FrameworkPOSIX

Threads…


SCOOPLI: a library for SCOOP

Implemented in Eiffel on .NET

Aim: try out solutions without bothering with compiler issues

Can serve as a basis for compiler implementations


Example: Bounded buffers

separate class BOUNDED_BUFFER [G]inherit

BOUNDED_QUEUE [G]end



class BUFFER_ACCESS [G]

feature

put (b: BOUNDED_BUFFER [G]; x: G) is -- Insert x into b.require not b.fulldo b.put (x)ensure not b.emptyend



remove (b: BOUNDED_BUFFER [G]) is -- Remove an element from brequire not b.emptydo b.removeensure not b.fullend

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

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: Elevator

In order to achieve maximal concurrency, all objectsare separate


Class BUTTON


Class BUTTON

separate class BUTTON

feature

target: INTEGER

end -- class BUTTON


Class CABIN_BUTTON

separate class CABIN_BUTTON

inherit BUTTON

feature

cabin: ELEVATOR

request is-- Send to associated elevator a request to stop on

level target. do

actual_request (cabin) end


Class CABIN_BUTTON

actual_request (e: ELEVATOR) is-- Get hold of e and send a request to stop on

level target. do

e.accept (target) end

end -- class CABIN_BUTTON


Class ELEVATOR

separate classELEVATOR

feature {BUTTON, DISPATCHER}

accept (floor: INTEGER) is-- Record and process a request to go to floor.

dorecord (floor)if not moving then process_requestend

end


Class ELEVATOR

feature {MOTOR}

record_stop (floor: INTEGER) is-- Record information that elevator has

stopped on the floor. do

moving := Falseposition := floor

process_request end


Class ELEVATOR

feature {NONE}

process_request is-- Handle next pending request, if any.

localfloor: INTEGER

doif not pending.is_empty then floor := pending.item actual_process (puller, floor) pending.removeend

end


Class ELEVATOR

actual_process (m: MOTOR; floor: INTEGER) is-- Handle next pending request, if any.

domoving := truem.move (floor)

end

feature {NONE}puller: MOTORpending: QUEUE [INTEGER]

-- Queue of pending requests.

end -- class ELEVATOR


Class MOTOR

separate class MOTOR

feature {ELEVATOR}

move (floor: INTEGER) is-- Go to floor; once there report.

do-- Direct the physical device to move to floorgui_main_window.move_elevator (cabin_number, floor)signal_stopped (cabin)

end

signal_stopped (e: ELEVATOR) is-- Report that elevator e stopped on level position.

doe.record_stop (position)

end


Class MOTOR

feature {NONE}cabin: ELEVATORposition: INTEGER

-- Current floor level.

gui_main_window: GUI_MAIN_WINDOW

end -- class MOTOR


Additional information

Nienaltowski P., Arslan V., Meyer B. Concurrent object-oriented programming on .NET, IEE Proceedings Software, Special Issue on ROTOR, October 2003.

Meyer B. Object-Oriented Software Construction, chapter 31, 2nd edition, Prentice Hall, 1997.

Project website

http://se.inf.ethz.ch/research/scoop

Date post:	19-Dec-2015
Category:	Documents
View:	216 times
Download:	0 times

Chair of Software Engineering OOSC Lecture 20 - Concurrency Object-Oriented Software Construction...

Documents