missing something). You have to encode your DAGs in term of communicating
process to make the whole scheduling process distributed. Believe me, it is
worth the effort since you'll then be able to try your algorithms in a very
-wide variety of conditions.
+wide variety of conditions. Here is an example of how you could do that.
+Assume T1 has to be done before T2.
+\verbatim
+ int your_agent(int argc, char *argv[] {
+ ...
+ T1 = MSG_task_create(...);
+ T2 = MSG_task_create(...);
+ ...
+ while(1) {
+ ...
+ if(cond) MSG_task_execute(T1);
+ ...
+ if((MSG_task_get_remaining_computation(T1)=0.0) && (you_re_in_a_good_mood))
+ MSG_task_execute(T2)
+ else {
+ /* do something else */
+ }
+ }
+ }
+\endverbatim
+
If you decide that the distributed part is not that much important and that
DAG is really the level of abstraction you want to work with (but it
prevents you from having "realistic" platform modeling), then you should
\section faq_troubleshooting Troubleshooting
+\subsection faq_distcheck_fails Dude! "make check" fails on my machine!
+
+Don't assume we never run this target, because we do. Really. Promise!
+
+There is several reasons which may cause the make check to fail on your
+machine:
+
+ - <b>You are using a borken compiler</b>.\n
+ The symptom may be that the "make check" fails within testsuite/gras
+ directory.\n
+ For example, the breezy release of Ubuntu comes with a prerelease of the
+ 4.0 gcc compiler. This version happens to be completely unusable, and you
+ should install a gcc-3.4 compiler and change the /usr/bin/gcc link to let
+ it point on /usr/bin/gcc-3.4.
+ - <b>You are using a borken libc (probably concerning the contextes)</b>.\n
+ The symptom is that the "make check" fails within the examples/msg directory.\n
+ By default, SimGrid uses something called ucontexts. This is part of the
+ libc, but it's quite undertested. For example, some (old) versions of the
+ glibc on alpha do not implement these functions, but provide the stubs
+ (which return ENOSYS: not implemented). It fools our detection mecanism
+ and leads to segfaults.\n
+ On some x86_64, the pointer to function is stored into a integer, but int
+ are 32bits only on this arch while pointers are 64bits. Our detection
+ mecanism also fails to detect the problem, which leads to segfaults.\n
+ In both cases, there is not much we can do to fix the bug. We are working
+ on a workaround for x86_64 machines, but in the meanwhile, you can
+ compile with --with-context=pthread to avoid ucontext completely. You'll
+ be a bit more limitated in the number of simulated processes you can start
+ concurently, but 5000 processes is still enough for most purposes, isn't
+ it?\n
+ This limitation is the reason why we insist on using this piece of ...
+ software even if it's so troublesome.
+ - <b>There is a bug in SimGrid we aren't aware of</b>.\n
+ If none of the above apply, please drop us a mail on the mailing list so
+ that we can check it out.
+
\subsection faq_context_1000 I want thousands of simulated processes
SimGrid can use either pthreads library or the UNIX98 contextes. On most
adapted version is picked up.
We experienced some issues with contextes on some rare systems (solaris 8
-and lower comes to mind). The main problem is that the configure script
-detect the contextes as being functional when it's not true. If you happen
-to use such a system, switch manually to the pthread version, and provide us
-with a good patch for the configure script so that it is done automatically ;)
+and lower or old alpha linuxes comes to mind). The main problem is that the
+configure script detect the contextes as being functional when it's not
+true. If you happen to use such a system, switch manually to the pthread
+version, and provide us with a good patch for the configure script so that
+it is done automatically ;)
\subsection faq_context_10000 I want hundred thousands of simulated processes
on your side... We have plenty of FAQ entries to redact and new
features to implement for the impenitents! ;)
-\author Arnaud Legrand (arnaud.legran::imag.fr)
+\author Arnaud Legrand (arnaud.legrand::imag.fr)
\author Martin Quinson (martin.quinson::loria.fr)
