here - Stefan-Marr.de
here - Stefan-Marr.de
here - Stefan-Marr.de
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
5. An Ownership-based MOP for Expressing Concurrency Abstractions<br />
the operations on the target object and thus, allow <strong>de</strong>velopers to adapt the<br />
language’s behavior as necessary. It is different from 3-KRS in that a target<br />
object can have multiple metaobjects associated with it. Furthermore, the semantics<br />
<strong>de</strong>fined by the proxy are only applied if a client interacts with the<br />
target object through the proxy, which can be a significant drawback. On the<br />
other hand, this <strong>de</strong>sign gives a large <strong>de</strong>gree of flexibility, since every target<br />
object can be adapted by arbitrarily many customizations as long as the client<br />
uses the proxy instead of the target object.<br />
Group-based Tanter further discusses the variation of group-based MOPs.<br />
Instead of having a distinct metaobject for every base-level object, for instance<br />
Mitchell et al. [1997] and Vallejos [2011] argue that it can be an advantage to<br />
enable a metaobject to <strong>de</strong>scribe the semantics of a set of objects. Mitchell et al.<br />
[1997] use meta-groups to control scheduling <strong>de</strong>cisions for base and metaobjects.<br />
Describing these semantics based on groups of objects instead of separate<br />
objects avoids the need for synchronization between multiple metaobjects,<br />
when scheduling <strong>de</strong>cisions have to be ma<strong>de</strong>.<br />
Message-based The message-reification-based mo<strong>de</strong>ls Tanter discusses provi<strong>de</strong><br />
a meta interface to specify the semantics of message sends, for instance<br />
by taking sen<strong>de</strong>r and receiver into account. For example, Ancona et al. [1998]<br />
propose a mo<strong>de</strong>l they call channel reification, which is based on messagereification.<br />
However, since the mo<strong>de</strong>l is based purely on communication and<br />
does not reify, e. g., object field access, it is too restrictive for our purposes.<br />
Conclusions Overall, metaobject protocols seem to be a good fit with the<br />
requirements i<strong>de</strong>ntified for a unifying substrate in multi-language VMs (cf.<br />
Sec. 3.4). However, some of the approaches do not provi<strong>de</strong> sufficient support<br />
to satisfy all of the requirements.<br />
The metaclass-based mo<strong>de</strong>l is too restrictive, because it is not orthogonal to<br />
application and library co<strong>de</strong>. Sec. 2.5 <strong>de</strong>scribes the vision of using the appropriate<br />
concurrent programming concepts for different challenges in a Mail<br />
application. It argues that event-loop-based actors are a good fit for implementing<br />
the user interface, while an STM is a good fit to interact with the<br />
database and to ensure data consistency. Consi<strong>de</strong>ring that such an application<br />
would rely on a number of third-party libraries for email protocols and<br />
user interface components, these libraries need to be usable in the context<br />
of event-loop actors as well as in the context of the STM. When using a<br />
112