Versatile Simulation of Distributed Systems
S4U classes are designed to be user process interfaces to Maestro resources. We provide an uniform interface to them:
intrusive_ptr_release(p)(which is the interface used by
pimpl(which is the Maestro object);
The ability to manipulate thge objects thought pointers and have the ability to use explicit reference count management is useful for creating C wrappers to the S4U and should play nicely with other language bindings (such as SWIG-based ones).
Some objects currently live for the whole duration of the simulation and do not have refertence counts. We still provide dummy
FooPtr for consistency.
In many cases, we try to have a API which is consistent with the API or corresponding C++ standard classes. For example, the methods of
simgrid::s4u::Mutex are based on
std::mutex. This has several benefits:
simgrid::s4u::Mutexcan be used with
It uses the
simgrid::simix::Process as a opaque pimple:
simgrid::kernel::Future class has been added to SimGrid as an abstraction to represent asynchronous operations in the SimGrid maestro. Its API is based on
std::experimental::future from the C++ Extensions for Concurrency Technical Specification:
simgrid::kernel::Future<T>represents the result an asynchronous operations in the simulation inside the SimGrid maestro/kernel;
simgrid::kernel::Promise<T>can be used to set the value of an assocaiated
The expected way to work with
simgrid::kernel::Future<T> is to add a completion handler/continuation:
The SimGrid kernel cannot block so calling
.wait() on a
simgrid::kernel::Future<T> which is not ready will deadlock. In practice, the simulator detects this and aborts after reporting an error.
In order to generate your own future, you might need to use a
simgrid::kernel::Promise<T>. The promise is a one-way channel which can be used to set the result of an associated
simgrid::kernel::Future<T> (with either
Like the experimental futures, we support chaining
.then() methods with automatic future unwrapping. You might want to look at some tutorial on C++ futures for more details and examples. Some operations of the proposed experimental futures are currently not implemented in our futures however such as
The current implementation of the model-checker uses two distinct processes:
simgrid-mc) itself lives in the parent process;
They communicate using a
SOCK_DGRAM socket and exchange messages defined in
SIMGRID_MC_SOCKET_FD environment variable it set to the file descriptor of this socket in the child process.
The model-checker analyzes, saves and restores the state of the model-checked process using the following techniques:
ptrace()s the model-checked process and is thus able to know the state of the model-checked process if it crashes;
AddressSpace is a base class used for both the model-checked process and its snapshots and has methods to read in the corresponding address space:
Processclass is a subclass representing the model-checked process;
Snapshotclass is a subclass representing a snapshot of the process.
Additional helper class include:
Remote<T>is the result of reading a
Tin a remote AddressSpace. For trivial types (int, etc.), it is convertible t o
RemotePtr<T>represents the address of an object of type
Tin some remote
AddressSpace(it could be an alias to
ELF is a standard executable file and dynamic libraries file format. DWARF is a standard for debug informations. Both are used on GNU/Linux systems and exploited by the model-checker to understand the model-checked process:
ObjectInformationrepresents the informations about a given ELF module (executable or shared-object);
Framerepresents a subprogram scope (either a subprogram or a scope within the subprogram);
Typerepresents a type (eg.
std::string) and is referenced by variables (global, variables, parameters), functions (return type), and other types (type of a
DwarfExpressionare used to describe the location of variables.