From: mquinson Date: Wed, 8 Apr 2009 10:22:10 +0000 (+0000) Subject: Add some more explaination about the network model used in GRAS, featuring a 'neat... X-Git-Tag: v3.3~25 X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/commitdiff_plain/c25fbc46b79d4193b64389ddd999b993450a95c4 Add some more explaination about the network model used in GRAS, featuring a 'neat' figure git-svn-id: svn+ssh://scm.gforge.inria.fr/svn/simgrid/simgrid/trunk@6221 48e7efb5-ca39-0410-a469-dd3cf9ba447f --- diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 2a1338360b..3db4b5094d 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -332,105 +332,8 @@ perform some more complex compilations... If you use the GRAS interface instead of the MSG one, then previous section is not the better source of information. Instead, you should check the GRAS tutorial in general, and the \ref GRAS_tut_tour_setup in particular. -*/ -\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux - -At the moment, we do not distribute Windows pre-compiled version of SimGrid -because the support for this platform is still experimental. We know that -some parts of the GRAS environment do not work, and we think that the others -environments (MSG and SD) have good chances to work, but we didn't test -ourselves. This section explains how we generate the SimGrid DLL so that you -can build it for yourself. First of all, you need to have a version more -recent than 3.1 (ie, a SVN version as time of writting). - -In order to cross-compile the package to windows from linux, you need to -install mingw32 (minimalist gnu win32). On Debian, you can do so by -installing the packages mingw32 (compiler), mingw32-binutils (linker and -so), mingw32-runtime. - -You can use the VPATH support of configure to compile at the same time for -linux and windows without dupplicating the source nor cleaning the tree -between each. Just run bootstrap (if you use the SVN) to run the autotools. -Then, create a linux and a win directories. Then, type: -\verbatim cd linux; ../configure --srcdir=.. ; make; cd .. -cd win; ../configure --srcdir=.. --host=i586-mingw32msvc ; make; cd .. -\endverbatim -The trick to VPATH builds is to call configure from another directory, -passing it an extra --srcdir argument to tell it where all the sources are. -It will understand you want to use VPATH. Then, the trick to cross-compile -is simply to add a --host argument specifying the target you want to build -for. The i586-mingw32msvc string is what you have to pass to use the mingw32 -environment as distributed in Debian. - -After that, you can run all make targets from both directories, and test -easily that what you change for one arch does not break the other one. - -It is possible that this VPATH build thing breaks from time to time in the -SVN since it's quite fragile, but it's granted to work in any released -version. If you experience problems, drop us a mail. - -Another possible source of issue is that at the moment, building the -examples request to use the gras_stub_generator tool, which is a compiled -program, not a script. In cross-compilation, you need to cross-execute with -wine for example, which is not really pleasant. We are working on this, but -in the meanwhile, simply don't build the examples in cross-compilation -(cd src before running make). - -Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be -usable. For example, if you want to test your build with wine, you should do -the following to put this library where wine looks for DLLs. -\verbatim -cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/ -gunzip ~/.wine/c/windows/system/mingwm10.dll.gz -\endverbatim -The DLL is builded in src/.libs, and installed in the prefix/bin directory -when you run make install. -If you want to use it in a native project on windows, you need to use -simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file -under linux (listing the defined symbols), and convert it into a .lib file -under windows (specifying this in a way that windows compilers like). To -generate the def files, run (under linux): -\verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def -echo EXPORTS >> simgrid.def -nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def -nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def - -echo "LIBRARY mingwm10.dll" > mingwm10.def -echo EXPORTS >> mingwm10.def -nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def -nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def -\endverbatim - -To create the import .lib files, use the lib windows tool (from -MSVC) the following way to produce simgrid.lib and mingwm10.lib -\verbatim lib /def:simgrid.def -lib /def:mingwm10.def -\endverbatim - -If you happen to use Borland C Builder, the right command line is the -following (note that you don't need any file.def to get this working). -\verbatim implib simgrid.lib libsimgrid-0.dll -implib mingwm10.lib mingwm10.dll -\endverbatim - -Then, set the following parameters in Visual C++ 2005: -Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib - -Just in case you wonder how to generate a DLL from libtool in another -project, we added -no-undefined to any lib*_la_LDFLAGS variables so that -libtool accepts to generate a dynamic library under windows. Then, to make -it true, we pass any dependencies (such as -lws2 under windows or -lpthread -on need) on the linking line. Passing such deps is a good idea anyway so -that they get noted in the library itself, avoiding the users to know about -our dependencies and put them manually on their compilation line. Then we -added the AC_LIBTOOL_WIN32_DLL macro just before AC_PROG_LIBTOOL in the -configure.ac. It means that we exported any symbols which need to be. -Nowadays, functions get automatically exported, so we don't need to load our -header files with tons of __declspec(dllexport) cruft. We only need to do so -for data, but there is no public data in SimGrid so we are good. -/*! \section faq_howto Feature related questions \subsection faq_MIA "Could you please add (your favorite feature here) to SimGrid?" @@ -1327,3 +1230,106 @@ specific at all, but it's full of good advices). */ +****************************************************************** +* OLD CRUFT NOT USED ANYMORE * +****************************************************************** + + +\subsection faq_crosscompile Cross-compiling a Windows DLL of SimGrid from linux + +At the moment, we do not distribute Windows pre-compiled version of SimGrid +because the support for this platform is still experimental. We know that +some parts of the GRAS environment do not work, and we think that the others +environments (MSG and SD) have good chances to work, but we didn't test +ourselves. This section explains how we generate the SimGrid DLL so that you +can build it for yourself. First of all, you need to have a version more +recent than 3.1 (ie, a SVN version as time of writting). + +In order to cross-compile the package to windows from linux, you need to +install mingw32 (minimalist gnu win32). On Debian, you can do so by +installing the packages mingw32 (compiler), mingw32-binutils (linker and +so), mingw32-runtime. + +You can use the VPATH support of configure to compile at the same time for +linux and windows without dupplicating the source nor cleaning the tree +between each. Just run bootstrap (if you use the SVN) to run the autotools. +Then, create a linux and a win directories. Then, type: +\verbatim cd linux; ../configure --srcdir=.. ; make; cd .. +cd win; ../configure --srcdir=.. --host=i586-mingw32msvc ; make; cd .. +\endverbatim +The trick to VPATH builds is to call configure from another directory, +passing it an extra --srcdir argument to tell it where all the sources are. +It will understand you want to use VPATH. Then, the trick to cross-compile +is simply to add a --host argument specifying the target you want to build +for. The i586-mingw32msvc string is what you have to pass to use the mingw32 +environment as distributed in Debian. + +After that, you can run all make targets from both directories, and test +easily that what you change for one arch does not break the other one. + +It is possible that this VPATH build thing breaks from time to time in the +SVN since it's quite fragile, but it's granted to work in any released +version. If you experience problems, drop us a mail. + +Another possible source of issue is that at the moment, building the +examples request to use the gras_stub_generator tool, which is a compiled +program, not a script. In cross-compilation, you need to cross-execute with +wine for example, which is not really pleasant. We are working on this, but +in the meanwhile, simply don't build the examples in cross-compilation +(cd src before running make). + +Program (cross-)compiled with mingw32 do request an extra DLL at run-time to be +usable. For example, if you want to test your build with wine, you should do +the following to put this library where wine looks for DLLs. +\verbatim +cp /usr/share/doc/mingw32-runtime/mingwm10.dll.gz ~/.wine/c/windows/system/ +gunzip ~/.wine/c/windows/system/mingwm10.dll.gz +\endverbatim + +The DLL is builded in src/.libs, and installed in the prefix/bin directory +when you run make install. + +If you want to use it in a native project on windows, you need to use +simgrid.dll and mingwm10.dll. For each DLL, you need to build .def file +under linux (listing the defined symbols), and convert it into a .lib file +under windows (specifying this in a way that windows compilers like). To +generate the def files, run (under linux): +\verbatim echo "LIBRARY libsimgrid-0.dll" > simgrid.def +echo EXPORTS >> simgrid.def +nm libsimgrid-0.dll | grep ' T _' | sed 's/.* T _//' >> simgrid.def +nm libsimgrid-0.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> simgrid.def + +echo "LIBRARY mingwm10.dll" > mingwm10.def +echo EXPORTS >> mingwm10.def +nm mingwm10.dll | grep ' T _' | sed 's/.* T _//' >> mingwm10.def +nm mingwm10.dll | grep ' D _' | sed 's/.* D _//' | sed 's/$/ DATA/' >> mingwm10.def +\endverbatim + +To create the import .lib files, use the lib windows tool (from +MSVC) the following way to produce simgrid.lib and mingwm10.lib +\verbatim lib /def:simgrid.def +lib /def:mingwm10.def +\endverbatim + +If you happen to use Borland C Builder, the right command line is the +following (note that you don't need any file.def to get this working). +\verbatim implib simgrid.lib libsimgrid-0.dll +implib mingwm10.lib mingwm10.dll +\endverbatim + +Then, set the following parameters in Visual C++ 2005: +Linker -> Input -> Additional dependencies = simgrid.lib mingwm10.lib + +Just in case you wonder how to generate a DLL from libtool in another +project, we added -no-undefined to any lib*_la_LDFLAGS variables so that +libtool accepts to generate a dynamic library under windows. Then, to make +it true, we pass any dependencies (such as -lws2 under windows or -lpthread +on need) on the linking line. Passing such deps is a good idea anyway so +that they get noted in the library itself, avoiding the users to know about +our dependencies and put them manually on their compilation line. Then we +added the AC_LIBTOOL_WIN32_DLL macro just before AC_PROG_LIBTOOL in the +configure.ac. It means that we exported any symbols which need to be. +Nowadays, functions get automatically exported, so we don't need to load our +header files with tons of __declspec(dllexport) cruft. We only need to do so +for data, but there is no public data in SimGrid so we are good. + diff --git a/doc/Makefile.am b/doc/Makefile.am index 01ea695b11..d189716281 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -7,7 +7,7 @@ DOCSOURCES = $(shell find @top_srcdir@/tools/gras @top_srcdir@/src @top_srcdir@/include -name "*.[chl]") \ $(shell find @srcdir@ -name "*.doc" |grep -v logcategories.doc) -FIGS=simgrid_modules.fig simgrid_modules2.fig amok_bw_test.fig amok_bw_sat.fig +FIGS=simgrid_modules.fig simgrid_modules2.fig amok_bw_test.fig amok_bw_sat.fig gras_comm.fig PNGS=$(patsubst %.fig,%.png,$(FIGS)) webcruft/simgrid_logo.png webcruft/simgrid_logo_small.png webcruft/poster_thumbnail.png EXTRA_DIST = html Doxyfile \ diff --git a/doc/fig/gras_comm.fig b/doc/fig/gras_comm.fig new file mode 100644 index 0000000000..ce48a403c9 --- /dev/null +++ b/doc/fig/gras_comm.fig @@ -0,0 +1,163 @@ +#FIG 3.2 Produced by xfig version 3.2.5 +Landscape +Center +Metric +A4 +100.00 +Single +-2 +1200 2 +5 1 0 1 0 7 50 -1 -1 0.000 0 0 0 0 3330.000 2475.000 3510 2340 3555 2475 3510 2610 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 0 0 6165.000 2250.000 5985 2115 5940 2250 5985 2385 +5 1 0 1 0 7 50 -1 -1 0.000 0 1 0 0 6052.500 2475.000 5985 2385 5940 2475 5985 2565 +6 2340 2250 3105 2475 +2 2 0 1 0 4 50 -1 20 0.000 0 0 -1 0 0 5 + 2925 2250 3015 2250 3015 2475 2925 2475 2925 2250 +4 2 0 50 -1 0 12 0.0000 4 195 735 3105 2430 send ( )\001 +-6 +1 3 0 1 0 7 40 -1 20 0.000 1 0.0000 5805 2250 90 90 5805 2250 5895 2250 +1 3 0 1 0 7 40 -1 20 0.000 1 0.0000 5805 2475 90 90 5805 2475 5895 2475 +1 3 0 1 0 7 40 -1 20 0.000 1 0.0000 3690 2475 90 90 3690 2475 3780 2475 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6030 2025 6030 4455 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 3375 2025 3375 4455 +2 2 0 1 0 1 50 -1 32 0.000 0 0 -1 0 0 5 + 3285 2115 3465 2115 3465 2610 3285 2610 3285 2115 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6030 2610 6345 2610 +2 2 0 1 0 5 50 -1 32 0.000 0 0 -1 0 0 5 + 3285 2610 3465 2610 3465 2880 3285 2880 3285 2610 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6030 3375 6345 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6435 3420 6705 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 6795 2025 6795 4455 +2 2 0 1 0 2 50 -1 32 0.000 0 0 -1 0 0 5 + 6705 2070 6885 2070 6885 3375 6705 3375 6705 2070 +2 2 0 1 0 31 50 -1 20 0.000 0 0 -1 0 0 5 + 7605 2160 7695 2160 7695 2385 7605 2385 7605 2160 +2 2 0 1 0 4 50 -1 20 0.000 0 0 -1 0 0 5 + 6345 2610 6435 2610 6435 3375 6345 3375 6345 2610 +2 2 0 1 0 31 50 -1 20 0.000 0 0 -1 0 0 5 + 6390 3375 6435 3375 6435 3510 6390 3510 6390 3375 +2 2 0 1 0 4 50 -1 20 0.000 0 0 -1 0 0 5 + 6345 3375 6390 3375 6390 3510 6345 3510 6345 3375 +2 2 0 1 0 5 50 -1 32 0.000 0 0 -1 0 0 5 + 6705 3375 6885 3375 6885 3510 6705 3510 6705 3375 +2 2 0 1 0 4 50 -1 20 0.000 0 0 -1 0 0 5 + 6345 3510 6435 3510 6435 3690 6345 3690 6345 3510 +2 2 0 1 0 5 50 -1 32 0.000 0 0 -1 0 0 5 + 6705 3510 6885 3510 6885 3690 6705 3690 6705 3510 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6439 3577 6709 3532 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 2115 6030 2385 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 3465 2115 6030 2115 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 2338 6030 2608 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 2340 4815 2475 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 2115 4815 2250 +2 2 0 1 0 1 50 -1 32 0.000 0 0 -1 0 0 5 + 3285 2880 3465 2880 3465 3375 3285 3375 3285 2880 +2 2 0 1 0 31 50 -1 20 0.000 0 0 -1 0 0 5 + 2925 3015 3015 3015 3015 3240 2925 3240 2925 3015 +2 2 0 1 0 1 50 -1 32 0.000 0 0 -1 0 0 5 + 6705 3690 6885 3690 6885 4185 6705 4185 6705 3690 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 7110 4545 7110 1710 5760 1710 5760 4545 7110 4545 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 6480 4410 6480 2160 6300 2160 6300 4410 6480 4410 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 4365 4545 4365 1755 3150 1755 3150 4545 4365 4545 +2 4 0 1 0 7 50 -1 -1 0.000 0 0 7 0 0 5 + 3870 4410 3870 2160 3690 2160 3690 4410 3870 4410 +2 2 0 1 0 23 50 -1 20 0.000 0 0 -1 0 0 5 + 3735 4050 3825 4050 3825 4275 3735 4275 3735 4050 +2 2 0 1 0 2 50 -1 32 0.000 0 0 -1 0 0 5 + 3285 3375 3465 3375 3465 4185 3285 4185 3285 3375 +2 2 0 1 0 5 50 -1 32 0.000 0 0 -1 0 0 5 + 3285 4185 3465 4185 3465 4365 3285 4365 3285 4185 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 4140 4185 3825 4185 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3735 4185 3465 4185 +2 2 0 1 0 23 50 -1 20 0.000 0 0 -1 0 0 5 + 2970 4140 3060 4140 3060 4365 2970 4365 2970 4140 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6705 3690 4140 3960 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 4140 4185 6705 4185 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6705 3913 4140 4183 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6705 3915 5355 4050 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 6705 3690 5355 3825 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 0 0 2 + 4140 2025 4140 4455 +2 2 0 1 0 31 50 -1 20 0.000 0 0 -1 0 0 5 + 8145 3240 8235 3240 8235 3465 8145 3465 8145 3240 +2 2 0 1 0 23 50 -1 20 0.000 0 0 -1 0 0 5 + 8415 3825 8505 3825 8505 4050 8415 4050 8415 3825 +2 2 0 1 0 23 50 -1 20 0.000 0 0 -1 0 0 5 + 5265 3825 5355 3825 5355 4050 5265 4050 5265 3825 +2 2 0 1 0 31 50 -1 20 0.000 0 0 -1 0 0 5 + 4815 3015 4905 3015 4905 3240 4815 3240 4815 3015 +2 2 0 1 0 4 50 -1 20 0.000 0 0 -1 0 0 5 + 4815 2250 4905 2250 4905 2475 4815 2475 4815 2250 +2 2 0 1 0 4 50 -1 20 0.000 0 0 -1 0 0 5 + 8820 3510 8910 3510 8910 3735 8820 3735 8820 3510 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 2880 6030 3150 +2 1 1 1 0 7 50 -1 -1 4.000 0 0 -1 0 0 2 + 6030 3375 3465 3375 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 3103 6030 3373 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 3105 4815 3240 +2 1 0 1 0 7 50 -1 -1 0.000 0 0 -1 1 0 2 + 1 1 1.00 45.00 45.00 + 3465 2880 4815 3015 +2 1 1 1 0 7 50 -1 -1 3.000 0 0 -1 0 0 2 + 6030 2610 3465 2610 +4 1 0 50 -1 0 12 0.0000 4 150 870 6345 1665 Process B\001 +4 1 0 50 -1 0 10 0.0000 4 105 480 6030 1935 listener\001 +4 1 0 50 -1 0 12 0.0000 4 150 900 3690 1665 Process A\001 +4 1 0 50 -1 0 10 0.0000 4 105 480 4095 1935 listener\001 +4 1 0 50 -1 0 10 0.0000 4 105 300 3375 1935 main\001 +4 2 0 50 -1 0 12 0.0000 4 165 750 3105 2790 compute\001 +4 1 0 50 -1 0 10 0.0000 4 105 300 6795 1935 main\001 +4 0 0 50 -1 0 12 0.0000 4 195 705 7155 2340 wait ( )\001 +4 1 0 30 -1 -1 10 0.0000 4 105 75 5804 2527 2\001 +4 1 0 30 -1 -1 10 0.0000 4 105 75 5804 2302 1\001 +4 1 0 30 -1 -1 10 0.0000 4 105 75 3689 2527 3\001 +4 0 0 50 -1 0 12 0.0000 4 195 1515 7200 4005 => send( )\001 +4 2 0 50 -1 0 12 0.0000 4 195 735 3105 3195 send ( )\001 +4 1 0 50 -1 1 10 0.0000 4 120 375 6390 2070 queue\001 +4 1 0 50 -1 1 10 0.0000 4 120 375 3780 2070 queue\001 +4 0 0 50 -1 0 12 0.0000 4 165 1050 7200 3465 compute on \001 +4 2 0 50 -1 0 12 0.0000 4 150 1395 3105 4320 => callback of \001 +4 2 0 50 -1 0 12 0.0000 4 195 1635 2745 3870 handle => wait any\001 +4 0 0 50 -1 0 12 0.0000 4 150 1875 7200 3690 handle => callback of \001 diff --git a/doc/gras_comm.png b/doc/gras_comm.png new file mode 100644 index 0000000000..53ec30027a Binary files /dev/null and b/doc/gras_comm.png differ diff --git a/doc/gtut-introduction.doc b/doc/gtut-introduction.doc index c7e28b9ae1..15450a5738 100644 --- a/doc/gtut-introduction.doc +++ b/doc/gtut-introduction.doc @@ -255,28 +255,85 @@ yourself will deadlock (althrough it may change in the future). \subsection GRAS_tut_intro_model_commmodel Communication model -Send operations are as synchronous as possible pratically. They -block the process until the message actually gets delivered to the receiving -process (an acknoledgment is awaited). We thus have an 1-port model in -emission. This limitation allows the framework to signal error condition +Send operations are as synchronous as possible pratically. They block +the process until the message actually gets delivered to the receiving +process. An acknoledgment is awaited in SG, and we consider the fact that RL +does not the same as a bug to be fixed one day. We thus have an 1-port model +in emission. This limitation allows the framework to signal error condition to the user code in the section which asked for the transmission, without having to rely on an interuption mecanism to signal errors asynchronously. -This communication model is not completely synchronous in that sense that -the receiver cannot be sure that the acknoledgment has been delivered -(this is the classical byzantin generals problem). Pratically, the -acknoledgment is so small that there is a good probability that the message -where delivered. If you need more guaranty, you will need to implement -better solutions in the user space. - -Receive operations can be done in parallel, thanks to a specific thread -within the framework. Moreover, the messages not matching the criterion in -explicite receive are queued. The model is thus N-port in reception. - -Previous paragraph describes the model we are targeting, but the current -state of the implementation is a bit different: an acknoledgment is awaited -in send operation only in SG (this is a bug of RL), and there is no specific -thread for handling incoming communications yet. This shouldn't last long -until we solve this. +This communication model is not completely synchronous in that sense that the +receiver cannot be sure that the acknoledgment has been delivered (this is the +classical byzantin generals problem). Pratically, the acknoledgment is so small +that there is a good probability that the message where delivered. If you need +more guaranty, you will need to implement better solutions in the user space. + +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. + +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 +the listener in charge of listening incoming messages from the network. Both +processes also have a queue for the communication between the two threads, even +if only the queue of process B is depicted in the graph. + +The experimental scenario is as follows:
    + +
  • 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 + 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.
    • + +
  • 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 + 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.
    • +
+ + + +This figure is a bit dense, and there is several point to detail here:
    + +
  • The timings associated to a given data exchange are detailed for the first +message. The time (1) corresponds to the network latency. That is the time to +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 +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 +were already received before it's actually delivered to the listener of machine +B (this would reduce the time (3)). To circumvent this, machine B should send a +little acknoledgment message when it's done, but this is not implemented yet.
    • + +
  • As you can see on the figure, sending is blocking until the message is +received by the listener on the other side, but the main thread of the receiver +side is not involved in this operation. Sender will get released from its send +even if the main thread of receiver is occuped elsewhere.
    • + +
  • Incomming messages not matching the expectations of a gras_msg_wait() (such +as the red one) are queued for further use. The next message receiving +operation will explore this queue in order, and if empty, block on the +network. The order of unexpected messages and subsequent ones is thus preserved +from the receiver point of view.
    • + +
  • 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 +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.
    • + +
\subsection GRAS_tut_intro_model_timing_policy Timing policy