1. Chair of Software Engineering OOSC - Summer Semester 2004 1 Object-Oriented Software Construction Bertrand Meyer

2. Chair of Software Engineering OOSC - Summer Semester 2004 2 Lecture 25: Concurrent O-O principles

3. Chair of Software Engineering OOSC - Summer Semester 2004 3 class BOUNDED_QUEUE [G] feature put (x: G) is -- Add x to queue. require not is_full do … ensure not is_empty end remove: G is -- Delete oldest element from queue. require not is_empty do … ensure not is_full end Design by Contract

4. Chair of Software Engineering OOSC - Summer Semester 2004 4 The contract model (cont’d) invariant maxcount = capacity – 1 0 <= oldest oldest <= capacity 0 <= next next <= capacity abs (next – oldest) < capacity end 1 oldest capacity maxcount next

5. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 6 The correctness of a class  (1-n) For every exported routine r: {INV and pre r } do r {INV and post r }  (1-m) For every creation procedure cp: {pre cp } do cp {post cp and INV} a.f (…) a.g (…) a.f (…) create a.make (…) S1 S2 S3 S4

7. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 8 Provability  Proof rule for routines: { INV  p } Body (r) { INV  q } p  Pre (r) q  Post (r) {p’ } Call (r) { q’ } p  Pre (r) q  Post (r)  In other words: to prove the validity of all calls, it suffices to prove (once!) the correctness of the body.

9. Chair of Software Engineering OOSC - Summer Semester 2004 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.remove q.put (x)  But: this does not work for separate threads of control!  What do preconditions now mean?

10. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 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. require not q.is_full do q.put (x) ensure not q.is_empty end

12. Chair of Software Engineering OOSC - Summer Semester 2004 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. require not q.is_empty do q.remove ensure not q.is_full end item (q: separate BOUNDED_QUEUE [G]): G is -- Oldest element not yet consumed... Left to reader... end

13. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 14 The original proof rule { INV  p } Body (r) { INV  q } p  Pre (r) q  Post (r) {p’ } Call (r) { q’ } p  Pre (r) q  Post (r)

15. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 16 Wait by necessity r (...; t: separate SOME_TYPE;...) is do... t.f (...) other_instructions end  When do we wait?

17. Chair of Software Engineering OOSC - Summer Semester 2004 17 Wait by necessity (cont’d)  For example: r (...; t: separate SOME_TYPE;...) is do... t.p (...) other_instruction_1... other_instruction_n k := t.some_value end  Wait on queries (calls to attributes and functions), not procedure calls. WAIT HERE

18. Chair of Software Engineering OOSC - Summer Semester 2004 18 Blocking semantics is not always appropriate f: FILE... if f /= Void and then f.readable then f.some_input_routine -- some_input_routine is any routine -- that reads data from the file; -- its precondition is readable. end

19. Chair of Software Engineering OOSC - Summer Semester 2004 19 Duels  Request immediate service: immediate_service  Accept immediate service: yield Exception in challenger Exception in holder; serve challenger. Challenger waits normal_serviceimmediate_service insist yield Challenger Holder

20. Chair of Software Engineering OOSC - Summer Semester 2004 20 Dining philosophers

21. Chair of Software Engineering OOSC - Summer Semester 2004 21 Dining philosophers (cont’d) separate class PHILOSOPHER inherit PROCESS rename setup as getup end create make feature {BUTLER} step is do think eat (left, right) end

22. Chair of Software Engineering OOSC - Summer Semester 2004 22 Dining philosophers (cont’d) feature {NONE} left, right: separate FORK -- The two required forks getup is -- Take any necessary initialization action. do... end think is -- Any appropriate action. do... end eat (l, r: separate FORK) is -- Eat, having grabbed l and r. do... end

23. Chair of Software Engineering OOSC - Summer Semester 2004 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 do Result := node_count (left) + node_count (right) + 1 end feature {NONE} node_count (b: BINARY_TREE [G]): INTEGER is -- Number of nodes in b do if b /= Void then Result := b.nodes end

24. Chair of Software Engineering OOSC - Summer Semester 2004 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. do nodes := 1 compute_nodes (left) compute_nodes (right) adjust_nodes (left) adjust_nodes (right) end

25. Chair of Software Engineering OOSC - Summer Semester 2004 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 then b.update_nodes end adjust_nodes (b: BINARY_TREE [G]) is -- Adjust number of nodes from those in b. do if b /= Void then nodes := nodes + b.nodes end

26. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 27 Two-level architecture SCOOP ….NETTHREADS

28. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 29 AppDomains “Almaviva”name landlord loved_one O1 “Figaro” O2 “Susanna” O3 Context AppDomain Process

30. Chair of Software Engineering OOSC - Summer Semester 2004 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. Chair of Software Engineering OOSC - Summer Semester 2004 31 End of lecture 25