X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/c25fbc46b79d4193b64389ddd999b993450a95c4..51c662a52164350714ff979ff89de9f9ea25410d:/doc/gtut-introduction.doc diff --git a/doc/gtut-introduction.doc b/doc/gtut-introduction.doc index 15450a5738..f53224e523 100644 --- a/doc/gtut-introduction.doc +++ b/doc/gtut-introduction.doc @@ -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 1-port in reception, 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 1-port model. 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 @@ -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 the -tutorial slides, but this not that important here. The time (3) is mainly +explained in the +slides of the HPCS'10, 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