correctly update the SonarQube URLs

[simgrid.git] / doc / doxygen / uhood.doc

diff --git a/doc/doxygen/uhood.doc b/doc/doxygen/uhood.doc
index d8d0a9b..b1ef22d 100644 (file)
--- a/doc/doxygen/uhood.doc
+++ b/doc/doxygen/uhood.doc
@@ -6,7 +6,6 @@ TBD
 
  - Simulation Loop, LMM, sharing -> papers
  - Context Switching, privatization -> papers
 
  - Simulation Loop, LMM, sharing -> papers
  - Context Switching, privatization -> papers

- - @subpage inside

 
 \section simgrid_uhood_s4u S4U
 
 
 \section simgrid_uhood_s4u S4U
 


@@ -17,7 +16,8 @@ We provide an uniform interface to them:
   (also called `simgrid::s4u::Foo::Ptr`);
 
 * manual reference count with `intrusive_ptr_add_ref(p)`,
   (also called `simgrid::s4u::Foo::Ptr`);
 
 * manual reference count with `intrusive_ptr_add_ref(p)`,

-  `intrusive_ptr_release(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);
 


@@ -25,7 +25,7 @@ We provide an uniform interface to them:
   (and share the same reference count).
 
 The ability to manipulate thge objects thought pointers and have the ability
   (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).
 
 to the S4U and should play nicely with other language bindings (such as
 SWIG-based ones).
 


@@ -35,7 +35,8 @@ 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
 
 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;
 


@@ -43,7 +44,9 @@ corresponding C++ standard classes. For example, the methods of
    standard interface;
 
  * we can use some standard C++ algorithms and helper classes with our types
    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`,
+   (`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`:
    etc.).
 
 Example of `simgris::s4u::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.
 
 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
 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
 
 
 \subsection simgrid_uhood_timer Timers
 


@@ -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
 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
 
 
  - `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);
 
  - `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);
 
  - `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.);
 
     by variables (global, variables, parameters), functions (return type),
     and other types (type of a `struct` field, etc.);