05.08.2014 Views

here - Stefan-Marr.de

here - Stefan-Marr.de

here - Stefan-Marr.de

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

6. Evaluation: The OMOP as a Unifying Substrate<br />

Furthermore, this section shows that the OMOP satisfies the requirements<br />

stated in Sec. 3.4. Tab. 6.2 recapitulates these requirements and the concrete<br />

properties an implementation needs to facilitate. Based on this table, this section<br />

<strong>de</strong>monstrates that the OMOP satisfies the requirements for managed<br />

state, managed execution, a notion of ownership, and controllable<br />

enforcement.<br />

For each case study, this section gives a brief introduction to the implementation<br />

and then <strong>de</strong>tails the ad hoc as well as the OMOP-based implementation.<br />

In or<strong>de</strong>r to evaluate the OMOP, it summarizes for each case study how the<br />

OMOP supported the solution of common implementation challenges.<br />

Table 6.1.: Common Challenges for the Implementation of Concurrent Programming<br />

Concepts on top of Multi-language VMs.<br />

Enforcement of<br />

Isolation<br />

Scheduling Policies<br />

Immutability<br />

Execution Policies<br />

State Access Policies<br />

• challenge to guarantee state encapsulation and safe message passing<br />

• by-value semantics problematic without proper ownership transfer<br />

• custom scheduler needs control over executed co<strong>de</strong><br />

• computational and primitive operations are problematic<br />

• used as as workaround to track mutation<br />

• reflection should obey it, when required<br />

• reflection should obey them, when required<br />

• implementation can be challenging without notion of ownership<br />

• reflection should obey them, when required<br />

• primitives need to be manageable to cover all state access<br />

• implementation can be challenging without notion of ownership<br />

6.2.1. Clojure Agents<br />

Introduction The main i<strong>de</strong>a of Clojure agents (cf. Sec. 2.4.3) is to ensure that<br />

only a single process, the process executing the agent’s event-loop, can write<br />

the agent’s state and to enforce immutability of all data structures referenced<br />

by an agent. To that end, an agent asynchronously receives update functions<br />

and processes them one by one. Note that Sec. 5.3.2 used agents earlier as an<br />

example to introduce the OMOP.<br />

In Clojure, the implementation is constructed in a way such that it is not<br />

possible to change the state by other means than by sending asynchronous<br />

142

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!