TBD
- Simulation Loop, LMM, sharing -> papers
- Context Switching, privatization -> papers
TBD
- Simulation Loop, LMM, sharing -> papers
- Context Switching, privatization -> papers
S4U classes are designed to be user process interfaces to Maestro resources.
We provide an uniform interface to them:
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
[`boost::intrusive_ptr`](http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html));
`intrusive_ptr_release(p)` (which is the interface used by
[`boost::intrusive_ptr`](http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html));
- the Maestro object and the corresponding S4U object have the same lifetime
(and share the same reference count).
- the Maestro object and the corresponding S4U object have the same lifetime
(and share the same reference count).
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
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
corresponding C++ standard classes. For example, the methods of
`simgrid::s4u::Mutex` are based on [`std::mutex`](http://en.cppreference.com/w/cpp/thread/mutex).
This has several benefits:
corresponding C++ standard classes. For example, the methods of
`simgrid::s4u::Mutex` are based on [`std::mutex`](http://en.cppreference.com/w/cpp/thread/mutex).
This has several benefits:
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
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
{
auto promise = std::make_shared<simgrid::kernel::Promise<void>>();
auto future = promise->get_future();
{
auto promise = std::make_shared<simgrid::kernel::Promise<void>>();
auto future = promise->get_future();
[`shared_future`](http://en.cppreference.com/w/cpp/thread/shared_future),
[`when_any()`](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0159r0.html#futures.when_any).
[`shared_future`](http://en.cppreference.com/w/cpp/thread/shared_future),
[`when_any()`](http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0159r0.html#futures.when_any).
The current implementation of the model-checker uses two distinct processes:
- the SimGrid model-checker (`simgrid-mc`) itself lives in the parent process;
The current implementation of the model-checker uses two distinct processes:
- the SimGrid model-checker (`simgrid-mc`) itself lives in the parent process;
- the model-cheker `ptrace()`s the model-checked process and is thus able to
know the state of the model-checked process if it crashes;
- the model-cheker `ptrace()`s the model-checked process and is thus able to
know the state of the model-checked process if it crashes;
variables;
- a custom heap is enabled in the model-checked process which allows the model
checker to know which chunks are allocated and which are freed.
variables;
- a custom heap is enabled in the model-checked process which allows the model
checker to know which chunks are allocated and which are freed.
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:
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:
- `RemotePtr<T>` represents the address of an object of type `T` in some
remote `AddressSpace` (it could be an alias to `Remote<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](http://refspecs.linuxbase.org/elf/elf.pdf) is a standard executable file
and dynamic libraries file format.
[ELF](http://refspecs.linuxbase.org/elf/elf.pdf) is a standard executable file
and dynamic libraries file format.
Both are used on GNU/Linux systems and exploited by the model-checker to
understand the model-checked process:
Both are used on GNU/Linux systems and exploited by the model-checker to
understand the model-checked process:
(executable or shared-object);
- `Frame` represents a subprogram scope (either a subprogram or a scope within
(executable or shared-object);
- `Frame` represents a subprogram scope (either a subprogram or a scope within