EXENCIONES TRIBUTARIAS POR COSTUMBRE (S.XIV)

Application developed using the single-threaded loop API.

Application developed using the parallel loop API.

Running on a single- threaded runtime

Native support. The single-threaded runtime will execute all the event handlers, with no noticeable speedup.

Running on the parallel event loop runtime

The PEV runtime might still try to execute handlers in parallel, al- ways enforcing the correct seman- tics.

The PEV runtime will schedule events in parallel as much possi- ble.

Table 3.1. API compatibility of the PEV.

3.2

Implicit parallelism and event ordering

In the PEV model, programs developed targeting a SEL system might potentially be executed in parallel by the runtime system, eventually enforcing the same semantics of the equivalent sequential execution. In the parallel programming literature such systems are usually called implicitly parallel systems[80], meaning that they provide developers with the impression of a single-threaded runtime system in which paral- lelization is done automatically. According to this definition, the PEV can be classified as an implicitly parallel runtime system. However, the compatibility requirement on FIFO-ordered events (needed to enforce the single-threaded loop compatibility) is not a strict requirement for every event handler. Indeed, certain events of specific classes can be processed with ordering others than FIFO.

In addition to FIFO event ordering, the PEV introduces two other classes of event handlers. The following three distinct classes of events are supported:

• Globally strictly ordered events (FIFO). Events that have to be executed respecting the same order they were added to the queue. Events of this class are the sole events supported by SEL runtimes.

• Chained ordering. Events that have to be processed only after a specific event has been processed, but not necessarily after all the other events in the queue. Events of this class have a logic dependence with other events, but can be executed out- of-order with respect to unrelated events.

• No ordering (unordered). Events that do not need to be processed with any or- dering, as they do not depend on any other event. Events of this class can be processed as soon as possible.

The three classes of events are defined in Figure 3.2. The PEV runtime system can speculatively attempt to parallelize the execution of all of the three classes of events,

30 3.2 Implicit parallelism and event ordering

Event class Semantics

Strictly ordered Every event that is selected for execution at in- stant T_i and needs to wait for an event already scheduled at instant T_i−1to complete before being executed. All side effects produced by the event at

T_i−1 are visible to the event T_i.

Chained An event that is selected for execution at instant

Ti and has to wait for some events at instant Ti−n,

for an arbitrary n with n< i.

Unordered An event that is selected for execution at instant

T_i, and does not have to wait for any other event before being safely scheduled.

Table 3.2. Event classes supported by the PEV.

meaning that also strictly ordered events might potentially be executed by multiple threads. This is depicted in Figure 3.2. The Figure presents the typical scenario for an event-based server-side framework like Node.JS. The service has received two in- coming concurrent connections, and is ready for processing them by having in its event queue all the events that have been triggered by the underlying operating system event emission substrate. A single-threaded event loop will process the events in the queue one by one, thus respecting the ordering in which events were emitted (a). When running in the PEV, however, events can be consumed by the runtime in different or- ders. When events are added to the queue with strict ordering, events are executed (potentially by more than one thread) enforcing the same ordering of single-threaded execution (b). Assuming the two connections can be processed in parallel, indepen- dently (this is often the case with stateless Web services), events can be consumed in parallel, just by assigning each thread a specific connection. This is equivalent to identifying a relation between events, which imposes that events belonging to distinct connections must be processed after events belonging to the same connection. This can be obtained by using chained events (c). Note that this approach to request han- dling is conceptually different from having two independent processes processing the two requests, as all the event handlers share the same memory space; indeed, this is equivalent to having a single process accepting two requests concurrently, in parallel. Finally, events respecting unordered processing (d) will respect an execution schema in which all events are executed as soon as possible2.

In a SEL system, the single-threaded nature of the runtime (and its centralized

2_{For this example, this might correspond to a potential violation of the semantics of the original}

Web service; still, unordered processing might be perfectly legal in other domains, for example when consuming unordered streams of elements coming from multiple distinct data sources.

31 3.3 Core parallel event emission API