here - Stefan-Marr.de

6.5. Discussion
Method Invocation Reification The ability to manage execution is essential
for active objects, actors, CSP, vats, and others. To this end, the OMOP
provides the #requestExecOf:on:with:lkup: intercession handler. The
case studies in Sec. 6.2 demonstrate how it can be used to customize
method execution policies, to enforce asynchronous execution for instance.
Removing this intercession handler from the OMOP would remove
its ability to facilitate different policies for method invocation, and
as a consequence significantly reduce the number of supported concepts
for which it can enforce guarantees.
Thread Resumption Event-loop actors and CSP require that only a single
thread executes the event loop or the program on shared mutable state.
Based on the notion of ownership and domains, these concepts require
control over the number of active threads. Since the thread itself is not
necessarily owned by a domain when it attempts to execute in that domain,
the resumption cannot be customized via custom method invocation
policies. Thus, the OMOP needs the #requestThreadResume: intercession
handler to capture this operation. Without it it would not be
possible to guarantee that the number of threads executing in a domain
be restricted.
Primitives Concrete primitives are specific to a VM. However, the notion of
primitives is available in all VMs. Primitives either make functionality
of the underlying platform available or they implement functionality
that cannot be expressed in the language that the VM implements.
Since such primitives are free to access object state, execute methods, or
change internal state of the VM, language implementers need to adapt
them in case they conflict with the semantics of a concurrent programming
concept. For instance, reflection is implemented via primitives and
needs to be subjected to concurrency semantics (cf. Sec. 3.3.5). To this
end, the OMOP provides the #prim* intercession handlers. It is required
because the primitives would otherwise void the desired semantics.
This section shows that the OMOP abstracts makes abstractions of concrete
concepts by providing mechanisms that enable their implementation. Furthermore,
for each mechanism of the OMOP it argues that it is required to satisfy
the purpose of a substrate for concurrent programming concepts. Thus, the
OMOP is minimal, because removing any of its parts would significantly decrease
its functionality and it would not be able to satisfy its requirements (cf.
Sec. 3.4).
175