doc/module-msg.doc

   1 /** \addtogroup MSG_API
   2
   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.
   6
   7       \section jMSG_who Who should use this (and who shouldn't)
   8
   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.
  14
  15   \section MSG_funct Offered functionnalities
  16    - \ref m_process_management
  17    - \ref m_datatypes_management
  18    - \ref m_host_management
  19    - \ref m_task_management
  20    - \ref m_file_management
  21    - \ref msg_actions_functions
  22    - \ref msg_gos_functions
  23    - \ref msg_easier_life
  24    - \ref msg_simulation
  25
  26   Also make sure to visit the page @ref MSG_examples.
  27 */
  28
  29
  30 /** @defgroup m_datatypes_management MSG Data Types
  31     @ingroup MSG_API
  32     @brief This section describes the different datatypes provided by MSG.
  33
  34     \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Data types" --> \endhtmlonly
  35 */
  36
  37 /** @defgroup m_process_management Management Functions of Agents
  38  *  @ingroup MSG_API
  39  *  @brief This section describes the agent structure of MSG
  40  *         (#m_process_t) and the functions for managing it.
  41  */
  42
  43 /** @defgroup m_host_management Management functions of Hosts
  44  *  @ingroup MSG_API
  45  *  @brief This section describes the host structure of MSG
  46  */
  47
  48 /** @defgroup m_task_management Managing functions of Tasks
  49  *  @ingroup MSG_API
  50  *  @brief This section describes the task structure of MSG
  51  *         (#m_task_t) and the functions for managing it.
  52  */
  53
  54  /** @defgroup m_file_management Managing functions of Files
  55  *  @ingroup MSG_API
  56  *  @brief This section describes the file structure of MSG
  57  *         (#m_file_t) and the functions for managing it. It
  58  *   is based on POSIX functions.
  59  */
  60
  61 /** @defgroup msg_actions_functions Managing actions
  62  *  @ingroup MSG_API
  63  *  @brief This section describes functions for managing actions.
  64  */
  65
  66 /** @defgroup msg_gos_functions MSG Operating System Functions
  67  *  @ingroup MSG_API
  68  *  @brief This section describes the functions that can be used
  69  *         by an agent for handling some task.
  70  */
  71
  72 /** @defgroup msg_easier_life      Platform and Application management
  73  *  @ingroup MSG_API
  74  *  @brief This section describes functions to manage the platform creation
  75  *         and the application deployment. Please check @ref
  76  *         MSG_examples for an overview of their usage.
  77  */
  78
  79 /** @defgroup msg_simulation   MSG simulation Functions
  80 *       @ingroup MSG_API
  81 *       @brief This section describes the functions you need to know to
  82 *       set up a simulation. You should have a look at \ref MSG_examples
  83 *       to have an overview of their usage.
  84 *
  85 *       @htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Simulation functions" --> @endhtmlonly
  86 */
  87
  88 /**
  89 @defgroup MSG_examples MSG Examples
  90 @ingroup MSG_API
  91
  92 MSG comes with an extensive set of examples. It is sometimes difficult
  93 to find the one you need. This list aims at helping you finding the
  94 example from which you can learn what you want to.
  95
  96 @section MSG_ex_basics Basic examples and features
  97
  98 */
  99
 100 /**
 101 @defgroup MSG_LUA      Lua bindings
 102 @ingroup MSG_API
 103 @brief Lua bindings to MSG (\ref MSG_API)
 104
 105 @htmlonly <!--  DOXYGEN_NAVBAR_LABEL="LUA bindings" --> @endhtmlonly
 106
 107       This is the lua bindings of the \ref MSG_API interface.
 108
 109       \section lMSG_who Who should use this (and who shouldn't)
 110
 111       If you want to use MSG to study your algorithm, but you don't
 112       want to use the C language (using \ref MSG_API), then you should
 113       use some bindings such as this one. The advantage of the lua
 114       bindings is that they are distributed directly with the main
 115       archive (in contrary to Java and Ruby bindings, for example,
 116       that are distributed separately). Another advantage of lua is
 117       that there is almost no performance loss with regard to the C
 118       version (at least there shouln't be any -- it is still to be
 119       precisely assessed).
 120
 121   \section MSG_Lua_funct  Lua offered functionnalities in MSG
 122   Almost all important features of the MSG interface are available
 123   from the lua bindings. Unfortunately, since doxygen does not support
 124   the lua modules implemented directly in C as we are using, there is
 125   no ready to use reference documentation for this module. Even more
 126   than for the other modules, you will have to dig into the source
 127   code of the examples to learn how to use it.
 128
 129   \section Lua_examples Examples of lua MSG
 130
 131    - \ref MSG_ex_master_slave_lua
 132    - \ref MSG_ex_master_slave_lua_bypass
 133    - Also, the lua version of the Chord example (in the source tree)
 134      is a working non-trivial example of use of the lua bindings
 135 */
 136
 137
 138 /** \defgroup MSG_ex_asynchronous_communications Asynchronous communications
 139     \ingroup MSG_examples
 140
 141     Simulation of asynchronous communications between a sender and a receiver using a realistic platform and
 142     an external description of the deployment.
 143
 144     \section MSG_ex_ms_TOC Table of contents:
 145      - \ref MSG_ext_icomms_code
 146        - \ref MSG_ext_icomms_preliminary
 147        - \ref MSG_ext_icomms_Sender
 148        - \ref MSG_ext_icomms_Receiver
 149        - \ref MSG_ext_icomms_core
 150        - \ref MSG_ext_icomms_Main
 151      - \ref MSG_ext_icomms_fct_Waitall
 152      - \ref MSG_ext_icomms_fct_Waitany
 153
 154     <hr>
 155
 156     \dontinclude msg/icomms/peer.c
 157
 158     \section MSG_ext_icomms_code Code of the application
 159
 160     \subsection MSG_ext_icomms_preliminary Preliminary declarations
 161     \skip include
 162     \until Sender function
 163
 164     \subsection MSG_ext_icomms_Sender Sender function
 165
 166     The sender send to a receiver an asynchronous message with the function "MSG_task_isend()". Cause this function is non-blocking
 167     we have to make "MSG_comm_test()" to know   if the communication is finished for finally destroy it with function "MSG_comm_destroy()".
 168     It also available to "make MSG_comm_wait()" which make both of them.
 169
 170       C style arguments (argc/argv) are interpreted as:
 171        - the number of tasks to distribute
 172        - the computation size of each task
 173        - the size of the files associated to each task
 174        - a list of host that will accept those tasks.
 175        - the time to sleep at the beginning of the function
 176        - This time defined the process sleep time
 177                         if time = 0 use of MSG_comm_wait()
 178                         if time > 0 use of MSG_comm_test()
 179
 180
 181     \until Receiver function
 182
 183     \subsection MSG_ext_icomms_Receiver Receiver function
 184
 185     This function executes tasks when it receives them. As the receiving is asynchronous we have to test the communication to know
 186     if it is completed or not with "MSG_comm_test()" or wait for the completion "MSG_comm_wait()".
 187
 188       C style arguments (argc/argv) are interpreted as:
 189        - the id to use for received the communication.
 190        - the time to sleep at the beginning of the function
 191        - This time defined the process sleep time
 192                         if time = 0 use of MSG_comm_wait()
 193                         if time > 0 use of MSG_comm_test()
 194
 195     \until Test function
 196
 197     \subsection MSG_ext_icomms_core Simulation core
 198
 199       This function is the core of the simulation and is divided only into 3 parts
 200       thanks to MSG_create_environment() and MSG_launch_application().
 201          -# Simulation settings : MSG_create_environment() creates a realistic
 202             environment
 203          -# Application deployment : create the agents on the right locations with
 204             MSG_launch_application()
 205          -# The simulation is run with #MSG_main()
 206
 207       Its arguments are:
 208         - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
 209         - <i>application_file</i>: the name of a file containing a valid surfxml application description
 210
 211     \until Main function
 212
 213     \subsection MSG_ext_icomms_Main Main function
 214
 215     This initializes MSG, runs a simulation, and free all data-structures created by MSG.
 216
 217     \until end_of_main
 218
 219     \dontinclude msg/icomms/peer2.c
 220
 221     \section MSG_ext_icomms_fct_Waitall Waitall function for sender
 222
 223     The use of this function permit to send all messages and wait for the completion of all in one time.
 224
 225     \skipline Sender function
 226     \until end_of_sender
 227
 228     \section MSG_ext_icomms_fct_Waitany Waitany function
 229
 230     The MSG_comm_waitany() function return the place of the first message send or receive from a xbt_dynar_t table.
 231
 232     \subsection MSG_ext_icomms_fct_Waitany_sender From a sender
 233         We can use this function to wait all sended messages.
 234     \dontinclude msg/icomms/peer3.c
 235     \skipline Sender function
 236     \until end_of_sender
 237
 238     \subsection MSG_ext_icomms_fct_Waitany_receiver From a receiver
 239         We can also wait for the receiving of all messages.
 240     \dontinclude msg/icomms/peer3.c
 241     \skipline Receiver function
 242     \until end_of_receiver
 243
 244 */
 245
 246 /** @defgroup MSG_ex_master_slave Basic Master/Slaves
 247     @ingroup MSG_examples
 248
 249     Simulation of a master-slave application using a realistic platform and
 250     an external description of the deployment.
 251
 252     \section MSG_ex_ms_TOC Table of contents:
 253
 254      - \ref MSG_ext_ms_code
 255        - \ref MSG_ext_ms_preliminary
 256        - \ref MSG_ext_ms_master
 257        - \ref MSG_ext_ms_slave
 258        - \ref MSG_ext_ms_forwarder
 259        - \ref MSG_ext_ms_core
 260        - \ref MSG_ext_ms_main
 261      - \ref MSG_ext_ms_helping
 262        - \ref MSG_ext_ms_application
 263        - \ref MSG_ext_ms_platform
 264
 265     <hr>
 266
 267     \dontinclude msg/masterslave/masterslave_forwarder.c
 268
 269     \section MSG_ext_ms_code Code of the application
 270
 271     \subsection MSG_ext_ms_preliminary Preliminary declarations
 272
 273     \skip include
 274     \until printf
 275     \until }
 276
 277     \subsection MSG_ext_ms_master Master code
 278
 279       This function has to be assigned to a m_process_t that will behave as the master.
 280       It should not be called directly but either given as a parameter to
 281       #MSG_process_create() or registered as a public function through
 282       #MSG_function_register() and then automatically assigned to a process through
 283       #MSG_launch_application().
 284
 285       C style arguments (argc/argv) are interpreted as:
 286        - the number of tasks to distribute
 287        - the computation size of each task
 288        - the size of the files associated to each task
 289        - a list of host that will accept those tasks.
 290
 291       Tasks are dumbly sent in a round-robin style.
 292
 293       \until end_of_master
 294
 295     \subsection MSG_ext_ms_slave Slave code
 296
 297       This function has to be assigned to a #m_process_t that has to behave as a slave.
 298       Just like the master fuction (described in \ref MSG_ext_ms_master), it should not be called directly.
 299
 300       This function keeps waiting for tasks and executes them as it receives them.
 301
 302       \until end_of_slave
 303
 304    \subsection MSG_ext_ms_forwarder Forwarder code
 305
 306       This function has to be assigned to a #m_process_t that has to behave as a forwarder.
 307       Just like the master function (described in \ref MSG_ext_ms_master), it should not be called directly.
 308
 309       C style arguments (argc/argv) are interpreted as a list of host
 310       that will accept those tasks.
 311
 312       This function keeps waiting for tasks and dispathes them to its slaves.
 313
 314       \until end_of_forwarder
 315
 316    \subsection MSG_ext_ms_core Simulation core
 317
 318       This function is the core of the simulation and is divided only into 3 parts
 319       thanks to MSG_create_environment() and MSG_launch_application().
 320          -# Simulation settings : MSG_create_environment() creates a realistic
 321             environment
 322          -# Application deployment : create the agents on the right locations with
 323             MSG_launch_application()
 324          -# The simulation is run with #MSG_main()
 325
 326       Its arguments are:
 327         - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
 328         - <i>application_file</i>: the name of a file containing a valid surfxml application description
 329
 330       \until end_of_test_all
 331
 332    \subsection MSG_ext_ms_main Main() function
 333
 334       This initializes MSG, runs a simulation, and free all data-structures created by MSG.
 335
 336       \until end_of_main
 337
 338    \section MSG_ext_ms_helping Helping files
 339
 340    \subsection MSG_ext_ms_application Example of application file
 341
 342    \include msg/masterslave/deployment_masterslave.xml
 343
 344    \subsection MSG_ext_ms_platform Example of platform file
 345
 346    \include msg/small_platform.xml
 347
 348 */
 349
 350 /** \page MSG_ex_master_slave_lua Master/slave Lua application
 351
 352     Simulation of a master-slave application using lua bindings
 353        - \ref MSG_ext_ms_code_lua
 354        - \ref MSG_ext_ms_master_lua
 355        - \ref MSG_ext_ms_slave_lua
 356        - \ref MSG_ext_ms_core_lua
 357
 358      - \ref MSG_ext_ms_helping
 359        - \ref MSG_ext_ms_application
 360        - \ref MSG_ext_ms_platform
 361
 362
 363       \dontinclude lua/masterslave/master_slave.lua
 364
 365       \section MSG_ext_ms_code_lua Code of the application
 366
 367       \subsection MSG_ext_ms_master_lua Master code
 368
 369             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.
 370
 371       Lua style arguments (...) in for the master are interpreted as:
 372        - the number of tasks to distribute
 373        - the computation size of each task
 374        - the size of the files associated to each task
 375        - a list of host that will accept those tasks.
 376
 377       Tasks are dumbly sent in a round-robin style.
 378
 379       \until end_of_master
 380
 381
 382       \subsection MSG_ext_ms_slave_lua Slave code
 383
 384       This function has to be assigned to a #m_process_t that has to behave as a slave.
 385       This function keeps waiting for tasks and executes them as it receives them.
 386
 387       \until end_of_slave
 388          \subsection MSG_ext_ms_core_lua Simulation core
 389
 390       in this section the core of the simulation which start by including the simgrid lib for bindings
 391       : <i>require "simgrid" </i>
 392
 393          -# Simulation settings : <i>simgrid.platform</i> creates a realistic
 394             environment
 395          -# Application deployment : create the agents on the right locations with
 396             <i>simgrid.application</i>
 397          -# The simulation is run with <i>simgrid.run</i>
 398
 399       Its arguments are:
 400         - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
 401         - <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
 402
 403       \until simgrid.clean()
 404
 405 */
 406
 407 /** \page MSG_ex_master_slave_lua_bypass Master/slave Bypass Lua application
 408
 409     Simulation of a master-slave application using lua bindings, Bypassing the XML parser
 410        - \ref MSG_ext_ms_code_lua
 411        - \ref MSG_ext_ms_master_lua
 412        - \ref MSG_ext_ms_slave_lua
 413        - \ref MSG_ext_ms_core_lua
 414
 415
 416       \dontinclude lua/console/master_slave_bypass.lua
 417
 418       \section MSG_ext_ms_code_lua Code of the application
 419
 420       \subsection MSG_ext_ms_master_lua Master code
 421
 422             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.
 423
 424       Lua style arguments (...) in for the master are interpreted as:
 425        - the number of tasks to distribute
 426        - the computation size of each task
 427        - the size of the files associated to each task
 428        - a list of host that will accept those tasks.
 429
 430       Tasks are dumbly sent in a round-robin style.
 431
 432       \until end_of_master
 433
 434
 435       \subsection MSG_ext_ms_slave_lua Slave code
 436
 437       This function has to be assigned to a #m_process_t that has to behave as a slave.
 438       This function keeps waiting for tasks and executes them as it receives them.
 439
 440       \until end_of_slave
 441          \subsection MSG_ext_ms_core_lua Simulation core
 442
 443       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.
 444       : <i>require "simgrid" </i>
 445
 446          -# Hosts : <i>simgrid.Host.new</i> instanciate a new host with an id, and power.
 447          -# Links : <i>simgrid.Link.new</i> instanictae a new link that will require an id, bandwith and latency values.
 448          -# Route : <i>simgrid.Route.new</i> define a route between two hosts specifying the links to use.
 449          -# Simulation settings : <i>simgrid.register_platform();</i> register own platform without using the XML SURF parser.
 450
 451          we can also bypass the XML deployment file, and associate functions for each of defined hosts.
 452         - <i>simgrid.Host.setFunction</i>: associate a function to a host, specifying arguments if needed.
 453         - <i>simgrid.register_application()</i>: saving the deployment settings before running the simualtion.
 454
 455       \until simgrid.clean()
 456
 457 */
 458