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