1 /** \addtogroup MSG_API
3 MSG was the first distributed programming environment provided within
4 SimGrid. While almost realistic, it remains quite simple (simplistic?).
5 This describes the native to MSG.
7 \section jMSG_who Who should use this (and who shouldn't)
9 You should use MSG if you want to study some heuristics for a
10 given problem you don't really want to implement. If you want to
11 use the C programming language, your are in the right
12 section. To use the Java or Ruby programming interfaces, please refer to
13 the documentation provided in the relevant packages.
15 \section MSG_funct Offered functionnalities
17 - \ref m_process_management
18 - \ref m_datatypes_management
19 - \ref m_host_management
20 - \ref m_task_management
21 - \ref msg_file_management
23 - \ref msg_trace_driven
24 - \ref msg_deprecated_functions
27 Also make sure to visit the page @ref MSG_examples.
31 @defgroup MSG_examples MSG Examples
34 @htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Examples" --> @endhtmlonly
36 MSG comes with an extensive set of examples. It is sometimes difficult
37 to find the one you need. This list aims at helping you finding the
38 example from which you can learn what you want to.
40 @section MSG_ex_basics Basic examples and features
45 @defgroup msg_simulation Main MSG simulation Functions
47 @brief Describes how to setup and control your simulation.
49 The basic workflow is the following (check the \ref MSG_examples for
52 -# Initialize the library with #MSG_global_init
53 -# Create a platform (usually by parsing a file with
54 #MSG_create_environment)
55 -# Register the functions that your processes are supposed to run with
56 #MSG_function_register (and maybe #MSG_function_register_default)
57 -# Launch your processes from a deployment file with #MSG_launch_application
58 -# Run the simulation with #MSG_main
59 -# Cleanup the library with #MSG_clean before ending your program
62 @htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Simulation Control" --> @endhtmlonly
66 /** @defgroup m_datatypes_management MSG Data Types
68 @brief This section describes the different datatypes provided by MSG.
70 \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Data types" --> \endhtmlonly
73 /** @defgroup m_process_management Process Management Functions
75 * @brief This section describes the process structure of MSG
76 * (#m_process_t) and the functions for managing it.
79 /** @defgroup m_host_management Host Management Functions
81 * @brief This section describes the host structure of MSG
84 /** @defgroup m_task_management Task Management Functions
86 * @brief This section describes the task structure of MSG
87 * (#m_task_t) and the functions for managing it. See
88 * \ref msg_task_usage to see how to put the tasks in action.
90 * \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Tasks" --> \endhtmlonly
93 /** @defgroup msg_task_usage Task Usage
95 * @brief This section describes the functions that can be used
96 * by a process to execute, communicate or otherwise handle some task.
99 /** @defgroup msg_file_management File Management Functions
101 * @brief This section describes the file structure of MSG
102 * (#msg_file_t) and the functions for managing it. It
103 * is based on POSIX functions.
108 @defgroup msg_trace_driven Trace-driven simulations
110 @brief This section describes the functions allowing to build trace-driven simulations.
112 \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Trace-Driven" --> \endhtmlonly
114 This is very handy when you want to test an algorithm or protocol that
115 does nothing unless it receives some events from outside. For example,
116 a P2P protocol reacts to requests from the user, but does nothing if
117 there is no such event.
119 In such situations, SimGrid allows to write your protocol in your C
120 file, and the events to react to in a separate text file. Declare a
121 function handling each of the events that you want to accept in your
122 trace files, register them using #MSG_action_register in your main,
123 and then use #MSG_action_trace_run to launch the simulation. You can
124 either have one trace file containing all your events, or a file per
127 Check the examples in <b>examples/msg/actions/actions.c</b> for details.
134 @defgroup MSG_LUA Lua bindings
136 @brief Lua bindings to MSG (\ref MSG_API)
138 @htmlonly <!-- DOXYGEN_NAVBAR_LABEL="LUA bindings" --> @endhtmlonly
140 This is the lua bindings of the \ref MSG_API interface.
142 \section lMSG_who Who should use this (and who shouldn't)
144 If you want to use MSG to study your algorithm, but you don't want to
145 use the C language (using \ref MSG_API), then you should use some
146 bindings such as this one. The advantage of the lua bindings is that
147 they are distributed directly with the main archive (in contrary to
148 Java and Ruby bindings, for example, that are distributed separately).
149 Another advantage of lua is that there is almost no performance loss
150 with regard to the C version (at least there shouln't be any -- it is
151 still to be precisely assessed).
153 \section MSG_Lua_funct Lua offered functionnalities in MSG
155 Almost all important features of the MSG interface are available from
156 the lua bindings. Unfortunately, since doxygen does not support the
157 lua modules implemented directly in C as we are using, there is no
158 ready to use reference documentation for this module. Even more than
159 for the other modules, you will have to dig into the source code of
160 the examples to learn how to use it.
162 \section Lua_examples Examples of lua MSG
164 - \ref MSG_ex_master_slave_lua
165 - \ref MSG_ex_master_slave_lua_bypass
166 - Also, the lua version of the Chord example (in the source tree)
167 is a working non-trivial example of use of the lua bindings
171 @defgroup msg_deprecated_functions MSG Deprecated
173 @brief This section describes the deprecated functions. PLEASE STOP USING THEM.
175 We don't remove them because the ability to run old scientific
176 code is something important to us. But these functionalities are
177 not actively supported anymore.
179 To access these functions, you should define the relevant option
180 at configuration time in ccmake.
185 @defgroup MSG_ex_asynchronous_communications Asynchronous communications
186 @ingroup MSG_examples
188 Simulation of asynchronous communications between a sender and a receiver using a realistic platform and
189 an external description of the deployment.
191 \section MSG_ex_ms_TOC Table of contents:
192 - \ref MSG_ext_icomms_code
193 - \ref MSG_ext_icomms_preliminary
194 - \ref MSG_ext_icomms_Sender
195 - \ref MSG_ext_icomms_Receiver
196 - \ref MSG_ext_icomms_core
197 - \ref MSG_ext_icomms_Main
198 - \ref MSG_ext_icomms_fct_Waitall
199 - \ref MSG_ext_icomms_fct_Waitany
203 \dontinclude msg/icomms/peer.c
205 \section MSG_ext_icomms_code Code of the application
207 \subsection MSG_ext_icomms_preliminary Preliminary declarations
209 \until Sender function
211 \subsection MSG_ext_icomms_Sender Sender function
213 The sender send to a receiver an asynchronous message with the function "MSG_task_isend()". Cause this function is non-blocking
214 we have to make "MSG_comm_test()" to know if the communication is finished for finally destroy it with function "MSG_comm_destroy()".
215 It also available to "make MSG_comm_wait()" which make both of them.
217 C style arguments (argc/argv) are interpreted as:
218 - the number of tasks to distribute
219 - the computation size of each task
220 - the size of the files associated to each task
221 - a list of host that will accept those tasks.
222 - the time to sleep at the beginning of the function
223 - This time defined the process sleep time
224 if time = 0 use of MSG_comm_wait()
225 if time > 0 use of MSG_comm_test()
228 \until Receiver function
230 \subsection MSG_ext_icomms_Receiver Receiver function
232 This function executes tasks when it receives them. As the receiving is asynchronous we have to test the communication to know
233 if it is completed or not with "MSG_comm_test()" or wait for the completion "MSG_comm_wait()".
235 C style arguments (argc/argv) are interpreted as:
236 - the id to use for received the communication.
237 - the time to sleep at the beginning of the function
238 - This time defined the process sleep time
239 if time = 0 use of MSG_comm_wait()
240 if time > 0 use of MSG_comm_test()
244 \subsection MSG_ext_icomms_core Simulation core
246 This function is the core of the simulation and is divided only into 3 parts
247 thanks to MSG_create_environment() and MSG_launch_application().
248 -# Simulation settings : MSG_create_environment() creates a realistic
250 -# Application deployment : create the processes on the right locations with
251 MSG_launch_application()
252 -# The simulation is run with #MSG_main()
255 - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
256 - <i>application_file</i>: the name of a file containing a valid surfxml application description
260 \subsection MSG_ext_icomms_Main Main function
262 This initializes MSG, runs a simulation, and free all data-structures created by MSG.
266 \dontinclude msg/icomms/peer2.c
268 \section MSG_ext_icomms_fct_Waitall Waitall function for sender
270 The use of this function permit to send all messages and wait for the completion of all in one time.
272 \skipline Sender function
275 \section MSG_ext_icomms_fct_Waitany Waitany function
277 The MSG_comm_waitany() function return the place of the first message send or receive from a xbt_dynar_t table.
279 \subsection MSG_ext_icomms_fct_Waitany_sender From a sender
280 We can use this function to wait all sent messages.
281 \dontinclude msg/icomms/peer3.c
282 \skipline Sender function
285 \subsection MSG_ext_icomms_fct_Waitany_receiver From a receiver
286 We can also wait for the arrival of all messages.
287 \dontinclude msg/icomms/peer3.c
288 \skipline Receiver function
289 \until end_of_receiver
294 @defgroup MSG_ex_master_slave Basic Master/Slaves
295 @ingroup MSG_examples
297 Simulation of a master-slave application using a realistic platform
298 and an external description of the deployment.
300 \section MSG_ex_ms_TOC Table of contents:
302 - \ref MSG_ext_ms_code
303 - \ref MSG_ext_ms_preliminary
304 - \ref MSG_ext_ms_master
305 - \ref MSG_ext_ms_slave
306 - \ref MSG_ext_ms_forwarder
307 - \ref MSG_ext_ms_core
308 - \ref MSG_ext_ms_main
309 - \ref MSG_ext_ms_helping
310 - \ref MSG_ext_ms_application
311 - \ref MSG_ext_ms_platform
315 \dontinclude msg/masterslave/masterslave_forwarder.c
317 \section MSG_ext_ms_code Code of the application
319 \subsection MSG_ext_ms_preliminary Preliminary declarations
325 \subsection MSG_ext_ms_master Master code
327 This function has to be assigned to a m_process_t that will behave as
328 the master. It should not be called directly but either given as a
329 parameter to #MSG_process_create() or registered as a public function
330 through #MSG_function_register() and then automatically assigned to a
331 process through #MSG_launch_application().
333 C style arguments (argc/argv) are interpreted as:
334 - the number of tasks to distribute
335 - the computation size of each task
336 - the size of the files associated to each task
337 - a list of host that will accept those tasks.
339 Tasks are dumbly sent in a round-robin style.
343 \subsection MSG_ext_ms_slave Slave code
345 This function has to be assigned to a #m_process_t that has to behave
346 as a slave. Just like the master fuction (described in \ref
347 MSG_ext_ms_master), it should not be called directly.
349 This function keeps waiting for tasks and executes them as it receives them.
353 \subsection MSG_ext_ms_forwarder Forwarder code
355 This function has to be assigned to a #m_process_t that has to behave
356 as a forwarder. Just like the master function (described in \ref
357 MSG_ext_ms_master), it should not be called directly.
359 C style arguments (argc/argv) are interpreted as a list of host that
360 will accept those tasks.
362 This function keeps waiting for tasks and dispathes them to its slaves.
364 \until end_of_forwarder
366 \subsection MSG_ext_ms_core Simulation core
368 This function is the core of the simulation and is divided only into 3 parts
369 thanks to MSG_create_environment() and MSG_launch_application().
370 -# Simulation settings : MSG_create_environment() creates a realistic
372 -# Application deployment : create the processes on the right locations with
373 MSG_launch_application()
374 -# The simulation is run with #MSG_main()
377 - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
378 - <i>application_file</i>: the name of a file containing a valid surfxml application description
380 \until end_of_test_all
382 \subsection MSG_ext_ms_main Main() function
384 This initializes MSG, runs a simulation, and free all data-structures created by MSG.
388 \section MSG_ext_ms_helping Helping files
390 \subsection MSG_ext_ms_application Example of application file
392 \include msg/masterslave/deployment_masterslave.xml
394 \subsection MSG_ext_ms_platform Example of platform file
396 \include msg/small_platform.xml
400 /** \page MSG_ex_master_slave_lua Master/slave Lua application
402 Simulation of a master-slave application using lua bindings
403 - \ref MSG_ext_ms_code_lua
404 - \ref MSG_ext_ms_master_lua
405 - \ref MSG_ext_ms_slave_lua
406 - \ref MSG_ext_ms_core_lua
408 - \ref MSG_ext_ms_helping
409 - \ref MSG_ext_ms_application
410 - \ref MSG_ext_ms_platform
413 \dontinclude lua/masterslave/master_slave.lua
415 \section MSG_ext_ms_code_lua Code of the application
417 \subsection MSG_ext_ms_master_lua Master code
419 as described ine the C native master/Slave exmaple , this function has to be assigned to a m_process_t that will behave as the master.
421 Lua style arguments (...) in for the master are interpreted as:
422 - the number of tasks to distribute
423 - the computation size of each task
424 - the size of the files associated to each task
425 - a list of host that will accept those tasks.
427 Tasks are dumbly sent in a round-robin style.
432 \subsection MSG_ext_ms_slave_lua Slave code
434 This function has to be assigned to a #m_process_t that has to behave as a slave.
435 This function keeps waiting for tasks and executes them as it receives them.
438 \subsection MSG_ext_ms_core_lua Simulation core
440 in this section the core of the simulation which start by including the simgrid lib for bindings
441 : <i>require "simgrid" </i>
443 -# Simulation settings : <i>simgrid.platform</i> creates a realistic
445 -# Application deployment : create the processes on the right locations with
446 <i>simgrid.application</i>
447 -# The simulation is run with <i>simgrid.run</i>
450 - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
451 - <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
453 \until simgrid.clean()
457 /** \page MSG_ex_master_slave_lua_bypass Master/slave Bypass Lua application
459 Simulation of a master-slave application using lua bindings, Bypassing the XML parser
460 - \ref MSG_ext_ms_code_lua
461 - \ref MSG_ext_ms_master_lua
462 - \ref MSG_ext_ms_slave_lua
463 - \ref MSG_ext_ms_core_lua
466 \dontinclude lua/console/master_slave_bypass.lua
468 \section MSG_ext_ms_code_lua Code of the application
470 \subsection MSG_ext_ms_master_lua Master code
472 as described ine the C native master/Slave exmaple , this function has to be assigned to a m_process_t that will behave as the master.
474 Lua style arguments (...) in for the master are interpreted as:
475 - the number of tasks to distribute
476 - the computation size of each task
477 - the size of the files associated to each task
478 - a list of host that will accept those tasks.
480 Tasks are dumbly sent in a round-robin style.
485 \subsection MSG_ext_ms_slave_lua Slave code
487 This function has to be assigned to a #m_process_t that has to behave as a slave.
488 This function keeps waiting for tasks and executes them as it receives them.
491 \subsection MSG_ext_ms_core_lua Simulation core
493 in this section the core of the simulation which start by including the simgrid lib for bindings, then create the resources we need to set up our environment bypassing the XML parser.
494 : <i>require "simgrid" </i>
496 -# Hosts : <i>simgrid.Host.new</i> instanciate a new host with an id, and power.
497 -# Links : <i>simgrid.Link.new</i> instanictae a new link that will require an id, bandwith and latency values.
498 -# Route : <i>simgrid.Route.new</i> define a route between two hosts specifying the links to use.
499 -# Simulation settings : <i>simgrid.register_platform();</i> register own platform without using the XML SURF parser.
501 we can also bypass the XML deployment file, and associate functions for each of defined hosts.
502 - <i>simgrid.Host.setFunction</i>: associate a function to a host, specifying arguments if needed.
503 - <i>simgrid.register_application()</i>: saving the deployment settings before running the simualtion.
505 \until simgrid.clean()