1. SCOOP: Simple Concurrent Object-Oriented Programming Extend the pure, strongly typed, object-oriented language Eiffel with a general and powerful concurrency and distribution model. SCOOP goals: Minimality of mechanism (only one new 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 Processors separate class BOUNDED_BUFFER [G] inherit BOUNDED_QUEUE [G] end To use a call such as q.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_ACCESS that fully encapsulates the notion of bounded buffer. indexing description: Encapsulation of access to bounded buffers" class BUFFER_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] Concurrent Object-Oriented Programming SCOOP Volkan Arslan, Bertrand Meyer, Piotr Nienaltowski Chair of Software Engineering, ETH Zurich, Switzerland 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 Systematic approach to deadlock prevention Precise fairness policies Proof rules, actual proofs GoalMethod Concurrency variants Challenges Example: Bounded Buffers SCOOP architecture To perform a computation is n 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. Need to declare whether client processor is the same as supplier processor or another. x: separate CLASS_X 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. 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 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. 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 The attempt to snatch a shared object from its current holder. Request immediate service: immediate_service Accept immediate service: yield Challenger Holder normal_serviceimmediate_service retainChallenger waitsException in challenger yieldChallenger waitsException in holder; serve challenger Processor assignment 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. Reserving an object Separate Entities Dual semantics of a call: Wait by necessity Duels Two-level architecture: First layer:Platform independent Second layer:Platform dependent