doc/module-msg.doc

   1 /** \defgroup MSG_JAVA      jMSG
   2     \ingroup MSG_API
   3     \brief Java bindings to MSG (\ref MSG_API)
   4
   5     \htmlonly <!--
   6       DOXYGEN_NAVBAR_LABEL="JAVA bindings"
   7       DOXYGEN_NAVBAR_CHILD "Simulation functions"=classsimgrid_1_1msg_1_1Msg.html
   8       DOXYGEN_NAVBAR_CHILD "Host"=classsimgrid_1_1msg_1_1Host.html
   9       DOXYGEN_NAVBAR_CHILD "Process"=classsimgrid_1_1msg_1_1Process.html
  10       DOXYGEN_NAVBAR_CHILD "Task"=classsimgrid_1_1msg_1_1Task.html
  11       DOXYGEN_NAVBAR_CHILD "MsgException"=classsimgrid_1_1msg_1_1MsgException.html
  12     --> \endhtmlonly
  13
  14       MSG was the first distributed programming environment provided within
  15       SimGrid. While almost realistic, it remains quite simple (simplistic?).
  16       This describes the Java bindings to this interface.
  17
  18       \section jMSG_who Who should use this (and who shouldn't)
  19
  20       You should use MSG if you want to study some heuristics for a
  21       given problem you don't really want to implement. If you want to
  22       use the Java programming language, your are in the right
  23       section. To use the C interface, please refer to \ref MSG_C.
  24 */
  25
  26 /** \defgroup MSG_C      MSG native
  27     \ingroup MSG_API
  28     \brief Native interface to MSG (\ref MSG_API)
  29
  30     \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Native interface" --> \endhtmlonly
  31
  32       MSG was the first distributed programming environment provided within
  33       SimGrid. While almost realistic, it remains quite simple (simplistic?).
  34       This describes the native to MSG.
  35
  36       \section jMSG_who Who should use this (and who shouldn't)
  37
  38       You should use MSG if you want to study some heuristics for a
  39       given problem you don't really want to implement. If you want to
  40       use the C programming language, your are in the right
  41       section. To use the Java programming interface, please refer to
  42       \ref MSG_JAVA.
  43 */
  44
  45
  46 /**
  47
  48 \defgroup MSG_LUA      lMSG
  49     \ingroup MSG_API
  50     \brief Lua bindings to MSG (\ref MSG_API)
  51
  52     \htmlonly <!--
  53       DOXYGEN_NAVBAR_LABEL="LUA bindings"
  54     --> \endhtmlonly
  55
  56       MSG was the first distributed programming environment provided within
  57       SimGrid. While almost realistic, it remains quite simple (simplistic?).
  58       This describes the Lua bindings to this interface.
  59
  60       \section lMSG_who Who should use this (and who shouldn't)
  61
  62       You should use MSG if you want to study some heuristics for a
  63       given problem you don't really want to implement. If you want to
  64       use the Lua script language, your are in the right
  65       section. To use the C interface, please refer to \ref MSG_C.
  66
  67 */
  68
  69 /** @addtogroup MSG_C
  70
  71   \section MSG_funct Offered functionnalities
  72    - \ref m_process_management
  73    - \ref m_datatypes_management
  74    - \ref m_host_management
  75    - \ref m_task_management
  76    - \ref msg_gos_functions
  77    - \ref m_channel_management
  78    - \ref msg_easier_life
  79    - \ref msg_simulation
  80
  81   \section MSG_examples Examples of MSG
  82
  83    - \ref MSG_ex_master_slave
  84    - \ref MSG_ex_asynchronous_communications
  85 */
  86
  87 /** @addtogroup MSG_LUA
  88
  89   \section MSG_Lua_funct  Lua offered functionnalities in MSG
  90    - \ref host_management
  91    - \ref tasks_management
  92    - \ref environment_management
  93   \section Lua_examples Examples of lua MSG
  94
  95    - \ref MSG_ex_master_slave_lua
  96    - \ref MSG_ex_master_slave_lua_bypass
  97 */
  98
  99
 100 /** @defgroup m_datatypes_management MSG Data Types
 101     @ingroup MSG_C
 102     @brief This section describes the different datatypes provided by MSG.
 103
 104     \htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Data types" --> \endhtmlonly
 105 */
 106 /**     \addtogroup m_process_management
 107         \ingroup MSG_C  */
 108 /**     \addtogroup m_host_management
 109         \ingroup MSG_C  */
 110 /**     \addtogroup m_task_management
 111         \ingroup MSG_C  */
 112 /**     \addtogroup msg_gos_functions
 113         \ingroup MSG_C  */
 114 /**     \addtogroup m_channel_management
 115         \ingroup MSG_C  */
 116 /**     \addtogroup msg_easier_life
 117         \ingroup MSG_C  */
 118 /**     \addtogroup msg_simulation
 119         \ingroup MSG_C  */
 120
 121 /** \page MSG_ex_asynchronous_communications Asynchronous communication applications
 122
 123     Simulation of asynchronous communications between a sender and a receiver using a realistic platform and
 124     an external description of the deployment.
 125
 126     \section MSG_ex_ms_TOC Table of contents:
 127      - \ref MSG_ext_icomms_code
 128        - \ref MSG_ext_icomms_preliminary
 129        - \ref MSG_ext_icomms_Sender
 130        - \ref MSG_ext_icomms_Receiver
 131        - \ref MSG_ext_icomms_core
 132        - \ref MSG_ext_icomms_Main
 133      - \ref MSG_ext_icomms_fct
 134
 135     <hr>
 136
 137     \dontinclude msg/icomms/peer.c
 138
 139     \section MSG_ext_icomms_code Code of the application
 140
 141     \subsection MSG_ext_icomms_preliminary Preliminary declarations
 142     \skip include
 143     \until Sender function
 144
 145     \subsection MSG_ext_icomms_Sender Sender function
 146
 147     The sender send to a receiver an asynchronous message with the function "MSG_task_isend()". Cause this function is non-blocking
 148     we have to make "MSG_comm_test()" to know   if the communication is finished for finally destroy it with function "MSG_comm_destroy()".
 149     It also available to "make MSG_comm_wait()" which make both of them.
 150
 151       C style arguments (argc/argv) are interpreted as:
 152        - the number of tasks to distribute
 153        - the computation size of each task
 154        - the size of the files associated to each task
 155        - a list of host that will accept those tasks.
 156        - the time to sleep at the beginning of the function
 157        - This time defined the process sleep time
 158                         if time = 0 use of MSG_comm_wait()
 159                         if time > 0 use of MSG_comm_test()
 160
 161
 162     \until Receiver function
 163
 164     \subsection MSG_ext_icomms_Receiver Receiver function
 165
 166     This function executes tasks when it receives them. As the receiving is asynchronous we have to test the communication to know
 167     if it is completed or not with "MSG_comm_test()" or wait for the completion "MSG_comm_wait()".
 168
 169       C style arguments (argc/argv) are interpreted as:
 170        - the id to use for received the communication.
 171        - the time to sleep at the beginning of the function
 172        - This time defined the process sleep time
 173                         if time = 0 use of MSG_comm_wait()
 174                         if time > 0 use of MSG_comm_test()
 175
 176     \until Test function
 177
 178     \subsection MSG_ext_icomms_core Simulation core
 179
 180       This function is the core of the simulation and is divided only into 3 parts
 181       thanks to MSG_create_environment() and MSG_launch_application().
 182          -# Simulation settings : MSG_create_environment() creates a realistic
 183             environment
 184          -# Application deployment : create the agents on the right locations with
 185             MSG_launch_application()
 186          -# The simulation is run with #MSG_main()
 187
 188       Its arguments are:
 189         - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
 190         - <i>application_file</i>: the name of a file containing a valid surfxml application description
 191
 192     \until Main function
 193
 194     \subsection MSG_ext_icomms_Main Main function
 195
 196     This initializes MSG, runs a simulation, and free all data-structures created by MSG.
 197
 198     \until end_of_main
 199
 200     \dontinclude msg/icomms/peer2.c
 201
 202     \section MSG_ext_icomms_fct Waitall function for sender
 203
 204     The use of this function permit to send all messages and wait for the completion of all in one time.
 205
 206     \skipline Sender function
 207     \until end_of_sender
 208
 209 */
 210
 211 /** \page MSG_ex_master_slave Master/slave application
 212
 213     Simulation of a master-slave application using a realistic platform and
 214     an external description of the deployment.
 215
 216     \section MSG_ex_ms_TOC Table of contents:
 217
 218      - \ref MSG_ext_ms_code
 219        - \ref MSG_ext_ms_preliminary
 220        - \ref MSG_ext_ms_master
 221        - \ref MSG_ext_ms_slave
 222        - \ref MSG_ext_ms_forwarder
 223        - \ref MSG_ext_ms_core
 224        - \ref MSG_ext_ms_main
 225      - \ref MSG_ext_ms_helping
 226        - \ref MSG_ext_ms_application
 227        - \ref MSG_ext_ms_platform
 228
 229     <hr>
 230
 231     \dontinclude msg/masterslave/masterslave_forwarder.c
 232
 233     \section MSG_ext_ms_code Code of the application
 234
 235     \subsection MSG_ext_ms_preliminary Preliminary declarations
 236
 237     \skip include
 238     \until printf
 239     \until }
 240
 241     \subsection MSG_ext_ms_master Master code
 242
 243       This function has to be assigned to a m_process_t that will behave as the master.
 244       It should not be called directly but either given as a parameter to
 245       #MSG_process_create() or registered as a public function through
 246       #MSG_function_register() and then automatically assigned to a process through
 247       #MSG_launch_application().
 248
 249       C style arguments (argc/argv) are interpreted as:
 250        - the number of tasks to distribute
 251        - the computation size of each task
 252        - the size of the files associated to each task
 253        - a list of host that will accept those tasks.
 254
 255       Tasks are dumbly sent in a round-robin style.
 256
 257       \until end_of_master
 258
 259     \subsection MSG_ext_ms_slave Slave code
 260
 261       This function has to be assigned to a #m_process_t that has to behave as a slave.
 262       Just like the master fuction (described in \ref MSG_ext_ms_master), it should not be called directly.
 263
 264       This function keeps waiting for tasks and executes them as it receives them.
 265
 266       \until end_of_slave
 267
 268    \subsection MSG_ext_ms_forwarder Forwarder code
 269
 270       This function has to be assigned to a #m_process_t that has to behave as a forwarder.
 271       Just like the master function (described in \ref MSG_ext_ms_master), it should not be called directly.
 272
 273       C style arguments (argc/argv) are interpreted as a list of host
 274       that will accept those tasks.
 275
 276       This function keeps waiting for tasks and dispathes them to its slaves.
 277
 278       \until end_of_forwarder
 279
 280    \subsection MSG_ext_ms_core Simulation core
 281
 282       This function is the core of the simulation and is divided only into 3 parts
 283       thanks to MSG_create_environment() and MSG_launch_application().
 284          -# Simulation settings : MSG_create_environment() creates a realistic
 285             environment
 286          -# Application deployment : create the agents on the right locations with
 287             MSG_launch_application()
 288          -# The simulation is run with #MSG_main()
 289
 290       Its arguments are:
 291         - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
 292         - <i>application_file</i>: the name of a file containing a valid surfxml application description
 293
 294       \until end_of_test_all
 295
 296    \subsection MSG_ext_ms_main Main() function
 297
 298       This initializes MSG, runs a simulation, and free all data-structures created by MSG.
 299
 300       \until end_of_main
 301
 302    \section MSG_ext_ms_helping Helping files
 303
 304    \subsection MSG_ext_ms_application Example of application file
 305
 306    \include msg/masterslave/deployment_masterslave.xml
 307
 308    \subsection MSG_ext_ms_platform Example of platform file
 309
 310    \include msg/small_platform.xml
 311
 312 */
 313
 314 /** \page MSG_ex_master_slave_lua Master/slave Lua application
 315
 316     Simulation of a master-slave application using lua bindings
 317        - \ref MSG_ext_ms_code_lua
 318        - \ref MSG_ext_ms_master_lua
 319        - \ref MSG_ext_ms_slave_lua
 320        - \ref MSG_ext_ms_core_lua
 321
 322      - \ref MSG_ext_ms_helping
 323        - \ref MSG_ext_ms_application
 324        - \ref MSG_ext_ms_platform
 325
 326
 327       \dontinclude lua/master_slave.lua
 328
 329       \section MSG_ext_ms_code_lua Code of the application
 330
 331       \subsection MSG_ext_ms_master_lua Master code
 332
 333             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.
 334
 335       Lua style arguments (...) in for the master are interpreted as:
 336        - the number of tasks to distribute
 337        - the computation size of each task
 338        - the size of the files associated to each task
 339        - a list of host that will accept those tasks.
 340
 341       Tasks are dumbly sent in a round-robin style.
 342
 343       \until end_of_master
 344
 345
 346       \subsection MSG_ext_ms_slave_lua Slave code
 347
 348       This function has to be assigned to a #m_process_t that has to behave as a slave.
 349       This function keeps waiting for tasks and executes them as it receives them.
 350
 351       \until end_of_slave
 352          \subsection MSG_ext_ms_core_lua Simulation core
 353
 354       in this section the core of the simulation which start by including the simgrid lib for bindings
 355       : <i>require "simgrid" </i>
 356
 357          -# Simulation settings : <i>simgrid.platform</i> creates a realistic
 358             environment
 359          -# Application deployment : create the agents on the right locations with
 360             <i>simgrid.application</i>
 361          -# The simulation is run with <i>simgrid.run</i>
 362
 363       Its arguments are:
 364         - <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
 365         - <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
 366
 367       \until simgrid.clean()
 368
 369 */
 370
 371 /** \page MSG_ex_master_slave_lua_bypass Master/slave Bypass Lua application
 372
 373     Simulation of a master-slave application using lua bindings, Bypassing the XML parser
 374        - \ref MSG_ext_ms_code_lua
 375        - \ref MSG_ext_ms_master_lua
 376        - \ref MSG_ext_ms_slave_lua
 377        - \ref MSG_ext_ms_core_lua
 378
 379
 380       \dontinclude lua/master_slave_bypass.lua
 381
 382       \section MSG_ext_ms_code_lua Code of the application
 383
 384       \subsection MSG_ext_ms_master_lua Master code
 385
 386             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.
 387
 388       Lua style arguments (...) in for the master are interpreted as:
 389        - the number of tasks to distribute
 390        - the computation size of each task
 391        - the size of the files associated to each task
 392        - a list of host that will accept those tasks.
 393
 394       Tasks are dumbly sent in a round-robin style.
 395
 396       \until end_of_master
 397
 398
 399       \subsection MSG_ext_ms_slave_lua Slave code
 400
 401       This function has to be assigned to a #m_process_t that has to behave as a slave.
 402       This function keeps waiting for tasks and executes them as it receives them.
 403
 404       \until end_of_slave
 405          \subsection MSG_ext_ms_core_lua Simulation core
 406
 407       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.
 408       : <i>require "simgrid" </i>
 409
 410          -# Hosts : <i>simgrid.Host.new</i> instanciate a new host with an id, and power.
 411          -# Links : <i>simgrid.Link.new</i> instanictae a new link that will require an id, bandwith and latency values.
 412          -# Route : <i>simgrid.Route.new</i> define a route between two hosts specifying the links to use.
 413          -# Simulation settings : <i>simgrid.register_platform();</i> register own platform without using the XML SURF parser.
 414
 415          we can also bypass the XML deployment file, and associate functions for each of defined hosts.
 416         - <i>simgrid.Host.setFunction</i>: associate a function to a host, specifying arguments if needed.
 417         - <i>simgrid.register_application()</i>: saving the deployment settings before running the simualtion.
 418
 419       \until simgrid.clean()
 420
 421 */