X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/a40e10b423680eebf86d42c0cd010d699b7b6c4d..c8213b8e0067bc5cbfa5e782fae6da918a80f7d3:/doc/doxygen/uhood.doc

diff --git a/doc/doxygen/uhood.doc b/doc/doxygen/uhood.doc
index d8d0a9bf46..7a750df1fb 100644
--- a/doc/doxygen/uhood.doc
+++ b/doc/doxygen/uhood.doc
@@ -6,26 +6,26 @@ TBD
 
  - Simulation Loop, LMM, sharing -> papers
  - Context Switching, privatization -> papers
- - @subpage inside
 
 \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)`,
-  `intrusive_ptr_release(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
-to use explicite reference count management is useful for creating C wrappers
+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).
 
@@ -35,18 +35,21 @@ not have refertence counts. We still provide dummy `intrusive_ptr_add_ref(p)`,
 
 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`. This has different benefits:
+`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
-   (`simgrid::s4u::Mutex` can be used with `std::lock`, `std::unique_lock`,
+ -  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 {
@@ -187,10 +190,12 @@ simgrid::kernel::Future<void> kernel_wait_until(double date)
 
 Like the experimental futures, we support chaining `.then()` methods with
 automatic future unwrapping.
-You might want to look at some [C++ tutorial on futures](https://www.youtube.com/watch?v=mPxIegd9J3w&list=PLHTh1InhhwT75gykhs7pqcR_uSiG601oh&index=43)
+You might want to look at some [tutorial on C++ futures](https://www.youtube.com/watch?v=mPxIegd9J3w&list=PLHTh1InhhwT75gykhs7pqcR_uSiG601oh&index=43)
 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()`.
+`.wait_for()`, `.wait_until()`,
+[`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
 
@@ -200,7 +205,7 @@ 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
@@ -210,15 +215,15 @@ 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
@@ -233,16 +238,18 @@ and its snapshots and has methods to read in the corresponding address space:
 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`.
+    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*>`).
 
 \subsection simgrid_uhood_mc_address_elf_dwarf ELF and DWARF
 
-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:
+[ELF](http://refspecs.linuxbase.org/elf/elf.pdf) is a standard executable file
+and dynamic libraries file format.
+[DWARF](http://dwarfstd.org/) 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);
@@ -250,7 +257,7 @@ and exploited by the model-checker to understand the model-checked process:
  - `Frame` represents a subprogram scope (either a subprogram or a scope within
     the subprogram);
 
- - `Type` represents a type (`char*`, `int`, `std::string`) and is referenced
+ - `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.);