SCOOP : S imple C oncurrent O bject- O riented P rogramming

1. Concurrent Object-Oriented Programming SCOOP Volkan Arslan, Bertrand Meyer, Piotr Nienaltowski Chair of Software Engineering, ETH Zurich, Switzerland Example: Bounded Buffers Goal Method • separate class BOUNDED_BUFFER [G] • inherit • BOUNDED_QUEUE [G] • end • To use a call such asq.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_ACCESSthat fully encapsulates the notion of bounded buffer. • indexing • description: “Encapsulation of access to bounded buffers" • classBUFFER_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] Processors Reserving an object • SCOOP: Simple Concurrent Object-OrientedProgramming • Extend the pure, strongly typed, object-orientedlanguage Eiffel with a general and powerful concurrencyand distribution model. • SCOOP goals: • Minimality of mechanism (onlyonenew keyword) • Full use of inheritance and other object-oriented techniques • Compatibility with Design By Contract • Provability • Support for command-query distinction • Applicability to many forms of concurrency • Adaptability through libraries • Support for reuse of non-concurrent software • Support for deadlock avoidance 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. To perform a computation is • to use certain processors • to apply certain actions • to certain objects. Definition: processor A processor is an autonomous thread of control capable of supporting the sequential execution of instructions on one or more objects. Separate Entities Wait by necessity Need to declare whether client processor is the same as supplier processor or another. x: separateCLASS_X 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 k := t.some_value end Concurrency variants • 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 Processor assignment Duels 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. The attempt to snatch a shared object from its current holder. Request immediate service: immediate_service Accept immediate service: yield 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. 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. SCOOP architecture Challenges • Two-level architecture: • First layer: Platform independent • Second layer: Platform dependent • Systematic approach to deadlock prevention • Precise fairness policies • Proof rules, actual proofs