Advanced Topics in Object Technology

ATOT - Lecture 26, 30 June 2003

1

Chair of Software Engineering

Advanced Topics in Object Technology

Bertrand Meyer


2


Lecture 26:

Concurrent O-O principles


3


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


4


The contract model (cont’d)

invariant

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

end

1oldest

capacity

maxcount

next


5


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


6


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


7


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.


8


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.


9


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?


10


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.


11


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


12


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


13


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


14


The original proof rule

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


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



15


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


16


Wait by necessity

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

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

end

When do we wait?


17


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


18


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


19


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


20


Dining philosophers


21


Dining philosophers (cont’d)

separate class PHILOSOPHER

inherit PROCESS

rename setup as getup

end

create

make

feature {BUTLER}step is

dothinkeat (left, right)

end


22


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


23


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


24


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


25


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


26


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)


27


Two-level architecture

SCOOP

….NET THREADS


28


.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


29


AppDomains

“Almaviva”name

landlord

loved_one

O1

“Figaro”O2

“Susanna”

O3

Context

Context

AppDomain AppDomainProcess


30


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


31


End of lecture 26

Advanced Topics in Object Technology

Documents

Transcript of Advanced Topics in Object Technology