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