37 tantes eran nuevos

queue I/O substrate Main thread emit emit emitChained (less than K attempts)

Work stealing emitNow emitChained emitUnordered Worker thread #N emit emitChained (K attempts) Worker thread #1

Figure 5.10. Hybrid runtime routing scheme.

The event handler waits until the sequence number of the next ordered event al- lowed to commit for the given event class matches its sequence number. Since se- quence numbers are unique and per-target, events with different event target will not interfere. At the moment the sequence number matches with the one of the next event handler allowed to commit, the method returns and the event handler can perform the final validation. Since event sequence numbers are unique, it is always guaranteed that the event will be the only one allowed to commit even in the case of conflicts with other event handlers, and the event handler will never abort because of a conflict with event handlers with higher commit sequence. Event handlers might still fail because of conflicts with event handlers belonging to other event targets (or unordered ones). The runtime does not privilege ordered events against unordered ones.

5.5

Hybrid runtime

The third implementation of the PEV runtime is represented by the Hybrid runtime. This implementation’s goal is to reduce the overhead for ordered events (as such events are the most common ones with single-threaded event loop runtimes) still offering good scalability for other workloads.

This hybrid PEV system is based on the principle of irrevocable transactions[154], transactions that are always allowed to commit, and therefore do not have to validate their metadata at commit time. This runtime system can be considered an hybrid ap- proach between the Pessimistic and the Optimistic runtimes, as it reduces the overhead for the main thread by employing a dedicated barrier for event handlers it executes, and makes use of optimistic speculation through a transactional memory to execute event handlers in the other threads.

90 5.5 Hybrid runtime

5.5.1

STM-based speculation

The STM runtime algorithm implemented by this PEV runtime is based on the Fast- Lane [151] algorithm, a software transactional memory runtime explicitly designed to reduce the execution overhead of STM systems by reducing the runtime barriers cost of one of the threads in charge of executing the transactions. Differently from the approach in the Optimistic runtime (where worker threads had the same type of trans- actional barriers except for the commit one), in FastLane two distinct types of barriers are used:

• Main thread: only the write operations need to implement runtime barriers. No logging is needed (nor for reads or writes), and both theTxStartandTxCommit

barriers simply need to acquire a globally shared lock.

• Worker threads: other threads have runtime barriers similar to the ones of TL2. Being the main thread in the system relying on very light barriers, a low execution overhead can be provided by the runtime for the majority of the workloads. By not hav- ing logs, the main thread cannot abort transactions, and therefore its transactions are always irrevocable. The advantage of having a fast, low-overhead main thread, comes at the price of scalability, as the irrevocable transaction might force other concurrent transactions to abort more often. Moreover, the need to acquire the global lock at the beginning of every irrevocable transaction has the effect of reducing the efficiency of worker threads. On the other hand, as long as transactions do not conflict, nor abort they can still contribute to the total throughput of the application.

5.5.2

Scheduling

The general scheduling strategy of the hybrid runtime is a combination of the schedul- ing strategy of the Pessimistic runtime and the one of the Optimistic runtime. Like with the Pessimistic PEV, every globally ordered event handler is executed by the main thread, including the ones emitted by the main thread and by other worker threads. In this way the main thread can offer low execution overhead for operations that are dominated by global events. As events different than globally ordered are emitted, however, they are sent by the main thread to worker threads. Like with the other run- times, hashing is used to schedule chained events, and like with the Optimistic runtime system, worker threads can perform work stealing. Tasks, however, can be stolen by idle threads only if they are unordered and can be executed in parallel. For chained events, the Hybrid runtime implements another execution strategy:

• Chained events are emitted either by the main thread or by a worker thread, and are added to the local queue of the proper (hashed) worker thread.

91 5.5 Hybrid runtime

Main thread Worker threads

emit In Received from Global queue Cannot receive

Out To Global queue To Global queue

emitChained In From main queue (After K attempts)

From local queue (emitted by worker itself) or from work stealing.

Out To hashed worker To local queue or hashed worker

emitNow In From main queue (After K attempts)

From local queue (emitted by worker itself) or from work stealing.

Out To random worker To local queue (might be stolen)

emitUnordered In From main queue (After K attempts)

From local queue (emitted by worker itself) or from work stealing.

Out To random worker To local queue (might be stolen)

Barriers FastLane Main FastLane Worker

Out-Of-order speculation Only for chained and unordered events (noemit)

Irrevocability Via main thread

Table 5.3. Hybrid PEV speculation summary.

• Once selected for execution, the event is run by the worker in a transaction. In case of failure, the transaction is not re-executed until it can commit, as in the Optimistic runtime. Conversely, after a number of K failures, the event handler is added to the global queue, and will therefore be executed by the main thread. The number of failures is a constant factor equivalent to the number of available cores in the system.

By adopting this simple contention management strategy, the execution overhead of conflicting event handlers is attenuated by the main thread. Since chained events already have to be executed following a fixed order, they will be executed in the main thread without violating the semantics of the PEV API, and at the same time the worker thread will have more opportunities for executing other tasks. In other words, the main thread is used to reduce contention on certain event handlers.

Work stealing is still possible between worker threads, but will affect only un- ordered and chained events. An overview of the scheduling policies of the Hybrid PEV runtime is presented in Table 5.3.