X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/c25fbc46b79d4193b64389ddd999b993450a95c4..c51823541276dc4b772e8c1c94dafb1291715268:/doc/gtut-introduction.doc

diff --git a/doc/gtut-introduction.doc b/doc/gtut-introduction.doc
index 15450a5738..01afc6bdbb 100644
--- a/doc/gtut-introduction.doc
+++ b/doc/gtut-introduction.doc
@@ -1,5 +1,5 @@
-/** 
-@page GRAS_tut_intro Introduction to the GRAS framework
+/** @defgroup GRAS_tut_intro What is GRAS
+    @ingroup GRAS_tut 
 
 \htmlinclude .gtut-introduction.doc.toc
 
@@ -209,7 +209,7 @@ Two main types of events may change the internal state of a given process:
    messages during the transition associated to this event.\n
    \n
    Incoming messages are not handled as soon as they arrive, but only when
-   the process declares to be ready to accept incomming events (using \ref
+   the process declares to be ready to accept incoming events (using \ref
    gras_msg_handle or related functions). It ensures that the treatment of a
    given message won't run in parallel to any other callback, so that
    process globals (its state) can be accessed and modified without
@@ -221,7 +221,7 @@ Two main types of events may change the internal state of a given process:
    \n
    Processes can also wait explicitely for incoming messages matching some
    given criterions (using \ref gras_msg_wait). Any messages received before the
-   one matching the criterions will be added to the incomming messages'
+   one matching the criterions will be added to the incoming messages'
    queue for further use. This may breaks the message delivery order.
    Moreover, there is no restriction on when this can be done. So, a
    callback to a given message can consume messages of other types. There is
@@ -272,7 +272,10 @@ As in SimGrid v3.3, receive operations are done in a separated thread, but they
 are done sequentially by this thread. The model is thus <b>1-port in
 reception</b>, but something like 2-port in general. Moreover, the messages not
 matching the criterion in explicite receive (see for example \ref
-gras_msg_wait) are queued for further use.
+gras_msg_wait) are queued for further use. Thanks to this specific
+thread, the emission and reception are completely decorelated. Ie, the
+main thread can perfectly send a message while the listener is
+receiving something. We thus have a classical <b>1-port model</b>.
 
 Here is a graphical representation of a scenario involving two processes A and
 B.  Both are naturally composed of two threads: the one running user code, and
@@ -284,14 +287,14 @@ The experimental scenario is as follows: <ul>
 
 <li>Process A sends a first message (depicted in red) with gras_msg_send(), do
     some more computation, and then send another message (depicted in
-    yellow). Then, this process handles any incomming message with
+    yellow). Then, this process handles any incoming message with
     gras_msg_handle(). Since no message is already queued in process A at this
     point, this is a blocking call until the third message (depicted in
     magenta) arrives from the other process.</li>
 
 <li>On its side, the process B explicitely wait for the second message with
     gras_msg_wait(), do some computation with it, and then call
-    gras_msg_handle() to handle any incomming message. This will pop the red
+    gras_msg_handle() to handle any incoming message. This will pop the red
     message from the queue, and start the callback attached to that kind of
     messages. This callback sends back a new message (depicted in magenta) back
     to process A.</li>
@@ -307,8 +310,8 @@ reach the machine on which B is running from the machine running on A. The time
 (2) is mainly given by the network bandwidth. This is the time for all bytes of
 the messages to travel from one machine to the other. Please note that the
 models used by SimGrid are a bit more complicated to keep realistic, as
-explained in <a href="http://www.loria.fr/~quinson/articles/simgrid-tutorial.pdf">the 
-tutorial slides</a>, but this not that important here. The time (3) is mainly
+explained in <a href="http://www.loria.fr/~quinson/blog/2010/06/28/Tutorial_at_HPCS/">the
+slides of the HPCS'10</a>, but this not that important here. The time (3) is mainly
 found in the SG version and not in RL (and that's a bug). This is the time to
 make sure that message were received on machine B. In real life, some buffering
 at system and network level may give the illusion to machine A that the message
@@ -328,7 +331,7 @@ network. The order of unexpected messages and subsequent ones is thus preserved
 from the receiver point of view.</li>
 
 <li>gras_msg_wait() and gras_msg_handle() accept timeouts as argument to
-specify how long you are willing to wait at most for incomming messages. These
+specify how long you are willing to wait at most for incoming messages. These
 were ignored here to not complexify the example any further. It is worth
 mentionning that the send operation cannot be timeouted. The existance of the
 listener should make it useless.</li>
@@ -338,7 +341,7 @@ listener should make it useless.</li>
 \subsection GRAS_tut_intro_model_timing_policy Timing policy
 
 All communication primitives allow 3 timout policies: one can only poll for
-incomming events (using timeout=0), wait endlessly for the communication to
+incoming events (using timeout=0), wait endlessly for the communication to
 be performed (using timeout<0) or specify a maximal delay to wait for the
 communication to proceed (using timeout>0, being a number of seconds).