The Type System A traitor is an entity that statically is declared as non-separate, but during execution can become attached to a separate object. Consistency Rules The rules Prevent almost all traitors and are easy to understand. Are too restrictive, don’t support agents and there is no soundness proof. The Type System of SCOOP We use the following notation: , where Attachable/detachable, Processor tag, is the current processor is some processor (top) is no processor (bottom) Ordinary type Examples We have the following subtyping rules Conformance on class types are like in Eiffel, essentially based on inheritance: Attached ≤ detachable: Any processor tag ≤ : In particular, non-separate ≤ : ≤ any processor tag: Feature call rule An expression exp of type is called controlled if and only if exp is attached and satisfies any of the following conditions: exp is non-separate, i.e.,
exp appears in a routine r that has an attached formal argument a with the same handler as exp, i.e., . A call x.f(a) appearing in the context of a routine r in C is valid if and only if both: x is controlled, and x’s base class exports feature f to C, and the actual arguments conform in number and type to formal arguments of f. Result type combinator: What is the type of a query call x.f(…)? Argument type combinator: What is the expected actual argument type in x.f(a)? Expanded objects are always attached and non-separate, and both type combinators preserve expanded types. traitors can be handled by object tests. An object test succeeds if the run-time type of its source conforms in all of detachability, locality, and class type to the type of its target. Genericity Entities of generic types may be separate, e.g. separate LIST[BOOK] Actual generic parameters may be separate, e.g. LIST[separate BOOK] All combinations are meaningful and useful. Lock Passing If a call x.f(a1,…,an) occurs in a routine r where one or more ai are controlled, the client’s handler (the processor executing r) passes all currently held locks to the handler of x, and waits until f terminates (synchronous). Lock passing combinations Contracts Precondition We have already seen that preconditions express the necessary requirement for a correct feature application, and that it is viewed as a synchronization mechanism: A called feature cannot be executed unless the precondition A violated precondition delays the feature’s execution.
A message consists of the target to whom the communication is addressed, and the content of the message. In Erlang, processes (i.e., actors) are created using spawn, which gives them a unique process identifier: Messages are sent by passing tuples to a PID with the ! syntax. Messages are retrieved from the mailbox using the receive function with pattern matching. Example: Partitioned Global Address Space (PGAS) Model and X10 Each processor has its own local memory, but the address space is unified. This allows processes on other processors to access remote data via simple assignment or dereference operations. X10 is an object-oriented language on the PGAS model. New threads can be spawned asynchronously; asynchronous PGAS model A memory partition and the threads operating on it are called a place. X10 operations async S Asynchronously spawns a new child thread executing S and returns immediately. finish S Executes S and waits until all asynchronously spawned child threads have terminated. atomic S Execute S atomically. S must be non-blocking, sequential and only access local data. when (E) S Conditional critical section: suspends the thread until E is true, then executes S atomically. E must be non-blocking, sequential, only access local data, and be side-effect free. at (p) S Execute S at place p. This blocks the current thread until completion of S.