SimGrid
3.21
Versatile Simulation of Distributed Systems
|
TBD
S4U classes are designed to be user process interfaces to Maestro resources. We provide an uniform interface to them:
simgrid::s4u::FooPtr
(also called simgrid::s4u::Foo::Ptr
);intrusive_ptr_add_ref(p)
, intrusive_ptr_release(p)
(which is the interface used by boost::intrusive_ptr
);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 intrusive_ptr_add_ref(p)
, intrusive_ptr_release(p)
and 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::Mutex
can be used with std::lock
, std::unique_lock
, etc.).Example of simgrid::s4u::Actor
:
It uses the simgrid::simix::Process
as a opaque pimple:
The 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 simgrid::kernel::Future<T>
.The expected way to work with simgrid::kernel::Future<T>
is to add a completion handler/continuation:
The SimGrid kernel cannot block so calling .get()
or .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 .set_value()
or .set_exception()
):
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 .wait_for()
, .wait_until()
, shared_future
, when_any()
.
The current implementation of the model-checker uses two distinct processes:
simgrid-mc
) itself lives in the parent process;They communicate using a AF_UNIX
SOCK_SEQPACKET
socket and exchange messages defined in mc_protocol.h
. The 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;The 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:
Process
class is a subclass representing the model-checked process;Snapshot
class is a subclass representing a snapshot of the process.Additional helper class include:
Remote<T>
is the result of reading a T
in a remote AddressSpace. For trivial types (int, etc.), it is convertible t o T
;RemotePtr<T>
represents the address of an object of type T
in some remote AddressSpace
(it could be an alias to Remote<T*>
).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:
ObjectInformation
represents the informations about a given ELF module (executable or shared-object);Frame
represents a subprogram scope (either a subprogram or a scope within the subprogram);Type
represents a type (eg. char*
, int
, std::string
) and is referenced by variables (global, variables, parameters), functions (return type), and other types (type of a struct
field, etc.);LocationList
and DwarfExpression
are used to describe the location of variables.