internals

= General Architecture

ROOT-Sim is a software library which is organizer as a three-tier architecture. The layers which compose the library are:

• Application Layer: It is the implementation of the simulation model. It only encloses the simulation logic, and exploits an interfaces with the Kernel Layer through a simple API (Tutorial: How to write a ROOT-Sim simulation model). The Application Layer can inject new events to be processed into the system, and it is triggered for their execution. In addition, it periodically receives a consistent and commited snapshot from the Kernel Layer on which control operations (like termination control or statistics printing) can be performed;
• Kernel Layer: It is the simulation platform’s core. It implements all the scheduling, memory management, communication, and housekeeping operations, providing a synchronization between all the Kernel instances. All these operations are completely trasparent towards the Application Layer;
• Communication Layer: This layer manages the inter-kernel communication. It relies on MPI standard.

The organization of the ROOT-Sim library is shown in <>.

RS-Arch .ROOT-Sim Architecture image::images/architettura-ROOTSim.png[ROOT-Sim Architecture]

A programmer who wants to exploit ROOT-Sim to achieve a distributed/parallel simulation only needs to implement the Simulation Object (Application Layer), relying on the platform’s API, which is documented here.

ROOT-Sim relies on a Master/Slave approach, the Master starts and coordinates all the distributed algorithms. The ROOT-Sim kernel presents a very modular architecture that allows a simple managment of any subsystem, providing a good extensibility and a good maintenance. A brief description of all the subsystems follows.

Event Manager

This module interfaces with the Application Layer and triggers the execution of the next upcpoming event. When the execution is complete, it gives control to the Memory Mangement subsystem in order to take a new snapshot of the simulation state in case the currently running policy is met. In addition, it checks if the event to be processed violates causality consistency (i.e., its timestamp preceedes the current Simulation Object’s Logical Virtual Time), triggering a rollback operation.

Scheduler

This module implements the system scheduler, which decides the next event to be executed. Two different scheduling algorithms are currently available, one that executes in linear time on the LPs number (suggested for simulations with a small number of LPs), and the other that executes in costant time (suggested for simulations with a big number of LPs). Both algorithms implement the Smallest Timestamp First (STF) policy, that according to several researches is less rollback-prone.

Memory Manager

This module manages Simulation Objects’ memory, by intercepting allocation/deallocation routines, and providing LPs state managment and Log and Restore mechanisms.

Global Virtual Time (GVT) Manager

This module implements the computation of the GVT that represents the committed horizon. Along with this computation, it performs some housekeeping operations to clean all the information preceeding the GVT that are no longer of interest for the platform.

Queue Manager

This module manages the messages queues. The system adopts the three following messages queues:

• Incoming Messages queue: This queue stores the messages (events) that have been delivered by the Simulation Kernel and are still to be processed. The messages remain in the queue until they are committed, which means that a their re-execution can not be requested because of a coasting forward operation;
• Outgoing Messages queue: This queue stores the messages that have been sent. They remain in the queue until a delivery-ack is received, in order to maintain system’s consistency throughout all the kernels;

Committed and Consistent Global State Manager

This module determines which are the per-LP committed and, if requested, also consistent states within the system through a distributed algorithm. Committed snapshots are then passed to the Application Layer via the OnGVT() function, so that the simulation logic is allowed to periodically perform checks on them.

== Source Code Organization

= Implementation Details