1 /*! \page use Using SimGrid
3 SimGrid comes with many examples provided in the examples/ directory. Those examples are described in section \ref MSG_examples . Those examples are commented and should be easy to understand. for a first step into SimGrid we also provide some more detailed examples in the sections below.
6 You should also check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a generic tutorial about using SimGrid.
10 \section using_msg Using MSG
12 You should also check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.
17 Here are some examples on how to use MSG, the most used API.
20 MSG comes with an extensive set of examples. It is sometimes difficult
21 to find the one you need. This list aims at helping you finding the
22 example from which you can learn what you want to.
24 \subsection MSG_ex_basics Basic examples and features
26 \subsubsection MSG_ex_asynchronous_communications Asynchronous communications
29 Simulation of asynchronous communications between a sender and a receiver using a realistic platform and
30 an external description of the deployment.
32 - \ref MSG_ext_icomms_code
33 - \ref MSG_ext_icomms_preliminary
34 - \ref MSG_ext_icomms_Sender
35 - \ref MSG_ext_icomms_Receiver
36 - \ref MSG_ext_icomms_core
37 - \ref MSG_ext_icomms_Main
38 - \ref MSG_ext_icomms_fct_Waitall
39 - \ref MSG_ext_icomms_fct_Waitany
43 \dontinclude msg/icomms/peer.c
45 \paragraph MSG_ext_icomms_code Code of the application
47 \paragraph MSG_ext_icomms_preliminary Preliminary declarations
49 \until Sender function
51 \paragraph MSG_ext_icomms_Sender Sender function
53 The sender send to a receiver an asynchronous message with the function "MSG_task_isend()". Cause this function is non-blocking
54 we have to make "MSG_comm_test()" to know if the communication is finished for finally destroy it with function "MSG_comm_destroy()".
55 It also available to "make MSG_comm_wait()" which make both of them.
57 C style arguments (argc/argv) are interpreted as:
58 - the number of tasks to distribute
59 - the computation size of each task
60 - the size of the files associated to each task
61 - a list of host that will accept those tasks.
62 - the time to sleep at the beginning of the function
63 - This time defined the process sleep time
64 if time = 0 use of MSG_comm_wait()
65 if time > 0 use of MSG_comm_test()
68 \until Receiver function
70 \paragraph MSG_ext_icomms_Receiver Receiver function
72 This function executes tasks when it receives them. As the receiving is asynchronous we have to test the communication to know
73 if it is completed or not with "MSG_comm_test()" or wait for the completion "MSG_comm_wait()".
75 C style arguments (argc/argv) are interpreted as:
76 - the id to use for received the communication.
77 - the time to sleep at the beginning of the function
78 - This time defined the process sleep time
79 if time = 0 use of MSG_comm_wait()
80 if time > 0 use of MSG_comm_test()
84 \paragraph MSG_ext_icomms_core Simulation core
86 This function is the core of the simulation and is divided only into 3 parts
87 thanks to MSG_create_environment() and MSG_launch_application().
88 -# Simulation settings : MSG_create_environment() creates a realistic
90 -# Application deployment : create the processes on the right locations with
91 MSG_launch_application()
92 -# The simulation is run with #MSG_main()
95 - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
96 - <i>application_file</i>: the name of a file containing a valid surfxml application description
100 \paragraph MSG_ext_icomms_Main Main function
102 This initializes MSG, runs a simulation, and free all data-structures created by MSG.
106 \dontinclude msg/icomms/peer2.c
108 \paragraph MSG_ext_icomms_fct_Waitall Waitall function for sender
110 The use of this function permit to send all messages and wait for the completion of all in one time.
112 \skipline Sender function
115 \paragraph MSG_ext_icomms_fct_Waitany Waitany function
117 The MSG_comm_waitany() function return the place of the first message send or receive from a xbt_dynar_t table.
119 \paragraph MSG_ext_icomms_fct_Waitany_sender From a sender
120 We can use this function to wait all sent messages.
121 \dontinclude msg/icomms/peer3.c
122 \skipline Sender function
125 \paragraph MSG_ext_icomms_fct_Waitany_receiver From a receiver
126 We can also wait for the arrival of all messages.
127 \dontinclude msg/icomms/peer3.c
128 \skipline Receiver function
129 \until end_of_receiver
131 \subsubsection MSG_ex_master_slave Basic Master/Slaves
133 Simulation of a master-slave application using a realistic platform
134 and an external description of the deployment.
136 \paragraph MSG_ex_ms_TOC Table of contents:
138 - \ref MSG_ext_ms_preliminary
139 - \ref MSG_ext_ms_master
140 - \ref MSG_ext_ms_slave
141 - \ref MSG_ext_ms_forwarder
142 - \ref MSG_ext_ms_core
143 - \ref MSG_ext_ms_main
144 - \ref MSG_ext_ms_helping
145 - \ref MSG_ext_ms_application
146 - \ref MSG_ext_ms_platform
150 \dontinclude msg/masterslave/masterslave_forwarder.c
153 \paragraph MSG_ext_ms_preliminary Preliminary declarations
159 \paragraph MSG_ext_ms_master Master code
161 This function has to be assigned to a msg_process_t that will behave as
162 the master. It should not be called directly but either given as a
163 parameter to #MSG_process_create() or registered as a public function
164 through #MSG_function_register() and then automatically assigned to a
165 process through #MSG_launch_application().
167 C style arguments (argc/argv) are interpreted as:
168 - the number of tasks to distribute
169 - the computation size of each task
170 - the size of the files associated to each task
171 - a list of host that will accept those tasks.
173 Tasks are dumbly sent in a round-robin style.
177 \paragraph MSG_ext_ms_slave Slave code
179 This function has to be assigned to a #msg_process_t that has to behave
180 as a slave. Just like the master fuction (described in \ref
181 MSG_ext_ms_master), it should not be called directly.
183 This function keeps waiting for tasks and executes them as it receives them.
187 \paragraph MSG_ext_ms_forwarder Forwarder code
189 This function has to be assigned to a #msg_process_t that has to behave
190 as a forwarder. Just like the master function (described in \ref
191 MSG_ext_ms_master), it should not be called directly.
193 C style arguments (argc/argv) are interpreted as a list of host that
194 will accept those tasks.
196 This function keeps waiting for tasks and dispathes them to its slaves.
198 \until end_of_forwarder
200 \paragraph MSG_ext_ms_core Simulation core
202 This function is the core of the simulation and is divided only into 3 parts
203 thanks to MSG_create_environment() and MSG_launch_application().
204 -# Simulation settings : MSG_create_environment() creates a realistic
206 -# Application deployment : create the processes on the right locations with
207 MSG_launch_application()
208 -# The simulation is run with #MSG_main()
211 - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
212 - <i>application_file</i>: the name of a file containing a valid surfxml application description
214 \until end_of_test_all
216 \paragraph MSG_ext_ms_main Main() function
218 This initializes MSG, runs a simulation, and free all data-structures created by MSG.
222 \subsubsection MSG_ext_ms_helping Helping files
224 \paragraph MSG_ext_ms_application Example of application file
226 \include msg/masterslave/deployment_masterslave.xml
228 \paragraph MSG_ext_ms_platform Example of platform file
230 \include msg/small_platform.xml
232 \section using_gras Using GRAS
234 Here are some examples on how to use GRAS.
236 You should also check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.
239 There is for now rather few examples of GRAS, but it's better than
248 \subsection GRAS_ex_ping Ping-Pong
250 This example implements the very classical ping-pong in GRAS. It
251 involves a client (initiating the ping-pong) and a server (answering to
254 It works the following way:
255 - Both the client and the server register all needed messages
256 - The server registers a callback to the ping message, which sends pong
258 - The client sends the ping message to the server, and waits for the
259 pong message as an answer.
261 This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
262 the code of the client and of the server is placed in the same file.
264 \subsubsection GRAS_ex_ping_toc Table of contents of the ping example
265 - \ref GRAS_ex_ping_common
266 - \ref GRAS_ex_ping_initial
267 - \ref GRAS_ex_ping_register
268 - \ref GRAS_ex_ping_server
269 - \ref GRAS_ex_ping_serdata
270 - \ref GRAS_ex_ping_sercb
271 - \ref GRAS_ex_ping_sermain
272 - \ref GRAS_ex_ping_client
273 - \ref GRAS_ex_ping_climain
277 \dontinclude gras/ping/ping_common.c
279 \subsubsection GRAS_ex_ping_common 1) Common code to the client and the server
281 \paragraph GRAS_ex_ping_initial 1.a) Initial settings
283 Let's first load the module header and declare a logging category (see
284 \ref XBT_log for more info on logging).
289 The module header <tt>ping.h</tt> reads:
291 \dontinclude gras/ping/ping.h
296 \paragraph GRAS_ex_ping_register 1.b) Register the messages
298 This function, called by both the client and the server is in charge of
299 declaring the existing messages to GRAS. Since the payload does not
300 involve any newly created types but only int, this is quite easy.
301 (to exchange more complicated types, see \ref GRAS_dd or
302 \ref GRAS_ex_mmrpc for an example).
304 \dontinclude gras/ping/ping_common.c
305 \skip register_messages
308 [Back to \ref GRAS_ex_ping_toc]
310 \subsubsection GRAS_ex_ping_server 2) Server's code
312 \paragraph GRAS_ex_ping_serdata 2.a) The server's globals
314 In order to ensure the communication between the "main" and the callback
315 of the server, we need to declare some globals. We have to put them in a
316 struct definition so that they can be handled properly in GRAS.
318 \dontinclude gras/ping/ping_server.c
322 \paragraph GRAS_ex_ping_sercb 2.b) The callback to the ping message
324 Here is the callback run when the server receives any ping message (this
325 will be registered later by the server).
327 \skip server_cb_ping_handler
328 \until end_of_server_cb_ping_handler
330 \paragraph GRAS_ex_ping_sermain 2.c) The "main" of the server
332 This is the "main" of the server. You must not write any main()
333 function yourself. Instead, you just have to write a regular function
334 like this one which will act as a main.
339 [Back to \ref GRAS_ex_ping_toc]
341 \subsubsection GRAS_ex_ping_client 3) Client's code
343 \paragraph GRAS_ex_ping_climain 3.a) Client's "main" function
345 This function is quite straightforward, and the inlined comments should
346 be enough to understand it.
348 \dontinclude gras/ping/ping_client.c
352 [Back to \ref GRAS_ex_ping_toc]
354 \subsection GRAS_ex_token Token Ring example
356 This example implements the token ring algorithm. It involves several
357 nodes arranged in a ring (each of them have a left and a right neighbour)
358 and exchanging a "token". This algorithm is one of the solution to ensure
359 the mutual exclusion between distributed processes. There is only one
360 token at any time, so the process in its possession is ensured to be the
361 only one having it. So, if there is an action you want all processes to
362 do alternativly, but you cannot afford to have two processes doing it at
363 the same time, let the process having the token doing it.
365 Actually, there is a lot of different token ring algorithms in the
366 litterature, so this example implements one of them: the simplest one.
367 The ring is static (no new node can join it, and you'll get trouble if
368 one node dies or leaves), and nothing is done for the case in which the
371 - \ref GRAS_ex_stoken_deploy
372 - \ref GRAS_ex_stoken_global
373 - \ref GRAS_ex_stoken_callback
374 - \ref GRAS_ex_stoken_main
376 \subsection GRAS_ex_stoken_deploy 1) Deployment file
378 Here is the deployment file:
379 \include examples/gras/mutual_exclusion/simple_token/simple_token.xml
381 The neighbour of each node is given at startup as command line argument.
382 Moreover, one of the nodes is instructed by a specific argument (the one
383 on Tremblay here) to create the token at the begining of the algorithm.
385 \subsection GRAS_ex_stoken_global 2) Global definition
387 The token is incarned by a specific message, which circulates from node
388 to node (the payload is an integer incremented at each hop). So, the most
389 important part of the code is the message callback, which forwards the
390 message to the next node. That is why we have to store all variable in a
391 global, as explained in the \ref GRAS_globals section.
393 \dontinclude examples/gras/mutual_exclusion/simple_token/simple_token.c
397 \subsection GRAS_ex_stoken_callback 3) The callback
399 Even if this is the core of this algorithm, this function is quite
402 \skip node_cb_stoken_handler
403 \until end_of_node_cb_stoken_handler
405 \subsection GRAS_ex_stoken_main 4) The main function
407 This function is splited in two parts: The first one performs all the
408 needed initialisations (points 1-7) while the end (point 8. below) calls
409 gras_msg_handle() as long as the planned amount of ring loops are not
415 \subsection GRAS_ex_mmrpc A simple RPC for matrix multiplication
417 This example implements a remote matrix multiplication. It involves a client
418 (creating the matrices and sending the multiplications requests) and a server
419 (computing the multiplication on client's behalf).
421 This example also constitutes a more advanced example of data description
422 mechanisms, since the message payload type is a bit more complicated than in
423 other examples such as the ping one (\ref GRAS_ex_ping).
425 It works the following way (not very different from the ping example):
426 - Both the client and the server register all needed messages and datatypes
427 - The server registers a callback to the "request" message, which computes
428 what needs to be and returns the result to the expeditor.
429 - The client creates two matrices, ask for their multiplication and check
432 This example resides in the <b>examples/gras/mmrpc/mmrpc.c</b> file.
434 \subsubsection GRAS_ex_mmrpc_toc Table of contents of the mmrpc example
435 - \ref GRAS_ex_mmrpc_common
436 - \ref GRAS_ex_mmrpc_header
437 - \ref GRAS_ex_mmrpc_dataregister
438 - \ref GRAS_ex_mmrpc_logdef
439 - \ref GRAS_ex_mmrpc_msgregister
440 - \ref GRAS_ex_mmrpc_server
441 - \ref GRAS_ex_mmrpc_serinc
442 - \ref GRAS_ex_mmrpc_sercb
443 - \ref GRAS_ex_mmrpc_sermain
444 - \ref GRAS_ex_mmrpc_client
445 - \ref GRAS_ex_mmrpc_cliinc
446 - \ref GRAS_ex_mmrpc_climain
451 \subsubsection GRAS_ex_mmrpc_common 1) Common code to the client and the server (mmrpc_common.c and mmrpc.h)
454 \paragraph GRAS_ex_mmrpc_header 1.a) Module header (mmrpc.h)
456 This loads the gras header and declare the function's prototypes as well
459 \dontinclude gras/mmrpc/mmrpc.h
464 \paragraph GRAS_ex_mmrpc_dataregister 1.b) Register the data types (mmrpc.h)
466 The messages involved in a matrix of double. This type is automatically
467 known by the GRAS mecanism, using the gras_datadesc_matrix() function of the
470 \paragraph GRAS_ex_mmrpc_logdef 1.c) Logging category definition (mmrpc_common.c)
472 Let's first load the module header and declare a logging category (see
473 \ref XBT_log for more info on logging). This logging category does live
474 in this file (ie the required symbols are defined here and declared as
475 "extern" in any other file using them). That is why we use
476 \ref XBT_LOG_NEW_DEFAULT_CATEGORY here and
477 \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY in mmrpc_client.c and mmrpc_server.c.
479 \dontinclude gras/mmrpc/mmrpc_common.c
483 \paragraph GRAS_ex_mmrpc_msgregister 1.d) Register the messages (mmrpc_common.c)
485 This function, called by both the client and the server is in charge of
486 declaring the existing messages to GRAS.
488 The datatype description builded that way can then be used to build an array datatype or
491 \skip register_messages
494 [Back to \ref GRAS_ex_mmrpc_toc]
496 \subsubsection GRAS_ex_mmrpc_server 2) Server's code (mmrpc_server.c)
498 \paragraph GRAS_ex_mmrpc_serinc 2.a) Server intial settings
500 All module symbols live in the mmrpc_common.c file. We thus have to
501 define \ref XBT_DEFINE_TYPE_EXTERN to the preprocessor so that the
502 \ref XBT_DEFINE_TYPE symbols don't get included here. Likewise, we use
503 \ref XBT_LOG_EXTERNAL_DEFAULT_CATEGORY to get the log category in here.
505 \dontinclude gras/mmrpc/mmrpc_server.c
509 \paragraph GRAS_ex_mmrpc_sercb 2.b) The callback to the mmrpc message
511 Here is the callback run when the server receives any mmrpc message (this
512 will be registered later by the server). Note the way we get the message
513 payload. In the ping example, there was one additional level of pointer
514 indirection (see \ref GRAS_ex_ping_sercb). This is because the payload is
515 an array here (ie a pointer) whereas it is a scalar in the ping example.
517 \skip server_cb_request_handler
518 \until end_of_server_cb_request_handler
520 \paragraph GRAS_ex_mmrpc_sermain 2.c) The "main" of the server
522 This is the "main" of the server. You must not write any main()
523 function yourself. Instead, you just have to write a regular function
524 like this one which will act as a main.
529 [Back to \ref GRAS_ex_mmrpc_toc]
531 \subsubsection GRAS_ex_mmrpc_client 3) Client's code (mmrpc_client.c)
533 \paragraph GRAS_ex_mmrpc_cliinc 2.a) Server intial settings
535 As for the server, some extra love is needed to make sure that automatic
536 datatype parsing and log categories do work even if we are using several
539 \dontinclude gras/mmrpc/mmrpc_client.c
543 \paragraph GRAS_ex_mmrpc_climain 3.b) Client's "main" function
545 This function is quite straightforward, and the inlined comments should
546 be enough to understand it.
548 \dontinclude gras/mmrpc/mmrpc_client.c
552 [Back to \ref GRAS_ex_mmrpc_toc]
554 \subsection GRAS_ex_timer Some timer games
556 This example fools around with the GRAS timers (\ref GRAS_timer). It is
557 mainly a regression test, since it uses almost all timer features.
559 The main program registers a repetititive task and a delayed one, and
560 then loops until the <tt>still_to_do</tt> variables of its globals reach
561 0. The delayed task set it to 5, and the repetititive one decrease it
562 each time. Here is an example of output:
563 \verbatim Initialize GRAS
565 [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
566 [1108335471] Programming the delayed_action for after 2.000000 sec
567 [1108335471] Have a rest
568 [1108335472] Canceling the delayed_action.
569 [1108335472] Re-programming the delayed_action for after 2.000000 sec
570 [1108335472] Repetitive_action has nothing to do yet
571 [1108335473] Repetitive_action has nothing to do yet
572 [1108335473] delayed_action setting globals->still_to_do to 5
573 [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
574 [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
575 [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
576 [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
577 [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
578 Exiting GRAS\endverbatim
581 - \ref GRAS_ex_timer_decl
582 - \ref GRAS_ex_timer_delay
583 - \ref GRAS_ex_timer_repeat
584 - \ref GRAS_ex_timer_main
588 \subsubsection GRAS_ex_timer_decl 1. Declarations and headers
592 \subsubsection GRAS_ex_timer_delay 2. Source code of the delayed action
593 \skip repetitive_action
594 \until end_of_repetitive_action
596 \subsubsection GRAS_ex_timer_repeat 3. Source code of the repetitive action
598 \until end_of_delayed_action
600 \subsubsection GRAS_ex_timer_main 4. Source code of main function
604 \section using_smpi Using SMPI
605 You should check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.
607 \section using_MC Using Model Checking
608 You should check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.
610 \section using_trace Using Trace
611 Check out the \ref tracing section.
613 You should check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.
615 \section using_simdag Using SimDag
616 You should check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.
618 \section using_simix Using SIMIX
619 You should check our online <a href="http://simgrid.gforge.inria.fr/tutorials/"> tutorial section</a> that contains a dedicated tutorial.