From 6e424d503426c74a02aeb94c78d1a905c59d6a56 Mon Sep 17 00:00:00 2001 From: mquinson Date: Sat, 11 Apr 2009 16:40:08 +0000 Subject: [PATCH 1/1] a new disabiguisation on the GRAS communication model git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk@6228 48e7efb5-ca39-0410-a469-dd3cf9ba447f --- doc/gtut-introduction.doc | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/doc/gtut-introduction.doc b/doc/gtut-introduction.doc index 15450a5738..9e89785913 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 -- 2.20.1