\section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start?
-You are at the right place... Having a look to these
-<a href="http://www.loria.fr/~quinson/blog/2010/06/28/Tutorial_at_HPCS/">the slides of the HPCS'10 tutorial</a>
-(or to these <a href="http://graal.ens-lyon.fr/~alegrand/articles/slides_g5k_simul.pdf">ancient
-slides</a>, or to these
-<a href="http://graal.ens-lyon.fr/~alegrand/articles/Simgrid-Introduction.pdf">"obsolete" slides</a>)
-may give you some insights on what SimGrid can help you to do and what
-are its limitations. Then you definitely should read the \ref
-MSG_examples.
+You are at the right place... To understand what you can do or
+cannot do with SimGrid, you should read the
+<a href="http://simgrid.gforge.inria.fr/tutorials.php">tutorial
+slides</a> from the SimGrid's website. You may find more uptodate
+material on the
+<a href="http://people.irisa.fr/Martin.Quinson/blog/SimGrid/">blog of
+Martin Quinson</a>.
+
+Another great source of inspiration can be found in the \ref msg_examples.
If you are stuck at any point and if this FAQ cannot help you, please drop us a
mail to the user mailing list: <simgrid-user@lists.gforge.inria.fr>.
\subsubsection faq_MIA_asynchronous I want to do asynchronous communications in MSG
-In the past (version <= 3.4), there was no function to perform asynchronous communications.
-It could easily be implemented by creating new process when needed though. Since version 3.5,
-we have introduced the following functions:
- - MSG_task_isend()
- - MSG_task_irecv()
- - MSG_comm_test()
- - MSG_comm_wait()
- - MSG_comm_waitall()
- - MSG_comm_waitany()
- - MSG_comm_destroy()
-
-We refer you to the description of these functions for more details on their usage as well
-as to the example section on \ref MSG_ex_asynchronous_communications.
-
-\subsubsection faq_MIA_thread_synchronization I need to synchronize my MSG processes
-
-You obviously cannot use pthread_mutexes of pthread_conds since we handle every
-scheduling related decision within SimGrid.
-
-In the past (version <=3.3.4) you could do it by playing with
-MSG_process_suspend() and MSG_process_resume() or with fake communications (using MSG_task_get(),
-MSG_task_put() and MSG_task_Iprobe()).
-
-Since version 3.4, you can use classical synchronization structures. See page \ref XBT_synchro or simply check in
-include/xbt/synchro_core.h.
+You are probably looking for the following functions:
+MSG_task_isend() and MSG_task_irecv();
+MSG_comm_test(), MSG_comm_wait(), MSG_comm_waitall() and MSG_comm_waitany();
+MSG_comm_destroy().
+
+There is even a specific example section on \ref msg_ex_async .
+
+\subsubsection faq_MIA_thread_synchronization How to synchronize my user processes?
+
+It depends on why you want to synchronize them. If you just want to
+have a shared state between your processes, then you probably don't
+need to do anything. User processes never get forcefully interrupted
+in SimGrid (unless you explicitly request the parallel execution of
+user processes -- see @ref options_virt_parallel).
+
+Even if several processes are executed at the exact same time within
+the simulation, they are linearized in reality by default: one process
+always run in an exclusive manner, atomic, uninterrupted until it does
+a simcall (until it ask a service from the simulation kernel). This is
+surprising at first, but things are much easier this way, both for the
+user (who don't have to protect her shared data) and for the kernel
+(that avoid many synchronization issues too). Processes are executed
+concurrently in the simulated realm, but you don't need to bother with
+this in the real realm.
+
+If you really need to synchronize your processes (because it's what
+you are studying or to create an atomic section that spans over
+several simcalls), you obviously cannot use regular synchronization
+mechanisms (pthread_mutexes in C or the synchronized keyword in Java).
+This is because the SimGrid kernel locks all processes and unlock them
+one after the other when they are supposed to run, until they give the
+control back in their simcall. If one of them gets locked by the OS
+before returning the control to the kernel, that's definitively a
+deadlock.
+
+Instead, you should use the synchronization mechanism provided by the
+simulation kernel. This could with a SimGrid mutex, a SimGrid
+condition variables or a SimGrid semaphore, as described in @ref
+msg_synchro (in Java, only semaphores are available). But actually,
+many synchronization patterns can be encoded with communication on
+mailboxes. Typically, if you need one process to notify another one,
+you could use a condition variable or a semphore, but sending a
+message to a specific mailbox does the trick in most cases.
\subsubsection faq_MIA_host_load Where is the get_host_load function hidden in MSG?
If you don't, you really should use valgrind to debug your code, it's
almost magic.
-\subsubsection faq_trouble_vg_longjmp longjmp madness in valgrind
-
-This is when valgrind starts complaining about longjmp things, just like:
-
-\verbatim ==21434== Conditional jump or move depends on uninitialised value(s)
-==21434== at 0x420DBE5: longjmp (longjmp.c:33)
-==21434==
-==21434== Use of uninitialised value of size 4
-==21434== at 0x420DC3A: __longjmp (__longjmp.S:48)
-\endverbatim
-
-This is the sign that you didn't used the exception mechanism well. Most
-probably, you have a <tt>return;</tt> somewhere within a <tt>TRY{}</tt>
-block. This is <b>evil</b>, and you must not do this. Did you read the section
-about \ref XBT_ex??
-
\subsubsection faq_trouble_vg_libc Valgrind spits tons of errors about backtraces!
It may happen that valgrind, the memory debugger beloved by any decent C
on your side... We have plenty of FAQ entries to redact and new
features to implement for the impenitents! ;)
-Using
-
\subsection faq_surf_network_latency I get weird timings when I play with the latencies.
OK, first of all, remember that units should be Bytes, Flops and