/*! @page uhood Under the Hood
-\tableofcontents
+@tableofcontents
TBD
- Simulation Loop, LMM, sharing -> papers
- Context Switching, privatization -> papers
-\section simgrid_uhood_s4u S4U
+@section simgrid_uhood_s4u S4U
S4U classes are designed to be user process interfaces to Maestro resources.
We provide an uniform interface to them:
-* automatic reference count with intrusive smart pointers `simgrid::s4u::FooPtr`
- (also called `simgrid::s4u::Foo::Ptr`);
+- automatic reference count with intrusive smart pointers `simgrid::s4u::FooPtr`
+ (also called `simgrid::s4u::Foo::Ptr`);
-* manual reference count with `intrusive_ptr_add_ref(p)`,
+- manual reference count with `intrusive_ptr_add_ref(p)`,
`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));
-* delegation of the operations to a opaque `pimpl` (which is the Maestro object);
+- delegation of the operations to a opaque `pimpl` (which is the Maestro object);
-* the Maestro object and the corresponding S4U object have the same lifetime
+- the Maestro object and the corresponding S4U object have the same lifetime
(and share the same reference count).
The ability to manipulate thge objects thought pointers and have the ability
`simgrid::s4u::Mutex` are based on [`std::mutex`](http://en.cppreference.com/w/cpp/thread/mutex).
This has several benefits:
- * we use a proven interface with a well defined and documented semantic;
+ - we use a proven interface with a well defined and documented semantic;
- * the interface is easy to understand and remember for people used to the C++
+ - the interface is easy to understand and remember for people used to the C++
standard interface;
- * we can use some standard C++ algorithms and helper classes with our types
+ - we can use some standard C++ algorithms and helper classes with our types
(`simgrid::s4u::Mutex` can be used with
[`std::lock`](http://en.cppreference.com/w/cpp/thread/lock),
[`std::unique_lock`](http://en.cppreference.com/w/cpp/thread/unique_lock),
etc.).
-Example of `simgris::s4u::Actor`:
+Example of `simgrid::s4u::Actor`:
~~~
class Actor {
}
~~~
-\section simgrid_uhood_async Asynchronous operations
+@section simgrid_uhood_async Asynchronous operations
-\subsection simgrid_uhood_futures Futures
+@subsection simgrid_uhood_futures Futures
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();
- SIMIX_timer_set(date, [promise] {
- promise->set_value();
- });
+ simgrid::simix::Timer::set(date, [promise] { promise->set_value(); });
return 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).
-\subsection simgrid_uhood_timer Timers
+@subsection simgrid_uhood_timer Timers
-\section simgrid_uhood_mc Model Checker
+@section simgrid_uhood_mc Model Checker
The current implementation of the model-checker uses two distinct processes:
- the SimGrid model-checker (`simgrid-mc`) itself lives in the parent process;
- - it spaws a child process for the SimGrid simulator/mastro and the simulated
+ - it spaws a child process for the SimGrid simulator/maestro and the simulated
processes.
-They communicate using a `AF_UNIX` `SOCK_DGRAM` socket and exchange messages
+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:
-* the model-checker reads and writes in the model-checked address space;
+- the model-checker reads and writes in the model-checked address space;
-* the model-cheker `ptrace()`s the model-checked process and is thus able to
+- 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;
-* DWARF debug informations are used to unwind the stack and identify local
+- DWARF debug informations are used to unwind the stack and identify local
variables;
-* a custom heap is enabled in the model-checked process which allows the model
+- 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.
-\subsection simgrid_uhood_mc_address_space Address space
+@subsection simgrid_uhood_mc_address_space 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*>`).
-\subsection simgrid_uhood_mc_address_elf_dwarf ELF and DWARF
+@subsection simgrid_uhood_mc_address_elf_dwarf ELF and DWARF
[ELF](http://refspecs.linuxbase.org/elf/elf.pdf) is a standard executable file
and dynamic libraries file format.
