You should use MSG if you want to study some heuristics for a
given problem you don't really want to implement. If you want to
use the C programming language, your are in the right
You should use MSG if you want to study some heuristics for a
given problem you don't really want to implement. If you want to
use the C programming language, your are in the right
@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Examples" --> @endhtmlonly
MSG comes with an extensive set of examples. It is sometimes difficult
@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="Examples" --> @endhtmlonly
MSG comes with an extensive set of examples. It is sometimes difficult
@defgroup msg_simulation Main MSG simulation Functions
@ingroup MSG_API
@brief Describes how to setup and control your simulation.
@defgroup msg_simulation Main MSG simulation Functions
@ingroup MSG_API
@brief Describes how to setup and control your simulation.
* @ingroup MSG_API
* @brief This section describes the process structure of MSG
* (#m_process_t) and the functions for managing it.
*/
* @ingroup MSG_API
* @brief This section describes the process structure of MSG
* (#m_process_t) and the functions for managing it.
*/
/** @defgroup m_host_management Host Management Functions
* @ingroup MSG_API
* @brief This section describes the host structure of MSG
*/
/** @defgroup m_host_management Host Management Functions
* @ingroup MSG_API
* @brief This section describes the host structure of MSG
*/
/** @defgroup m_task_management Task Management Functions
* @ingroup MSG_API
* @brief This section describes the task structure of MSG
/** @defgroup m_task_management Task Management Functions
* @ingroup MSG_API
* @brief This section describes the task structure of MSG
/** @defgroup msg_task_usage Task Actions
* @ingroup MSG_API
* @brief This section describes the functions that can be used
/** @defgroup msg_task_usage Task Actions
* @ingroup MSG_API
* @brief This section describes the functions that can be used
*
* With it, you can create virtual machines to put your processes
* into, and interact directly with the VMs to manage groups of
*
* With it, you can create virtual machines to put your processes
* into, and interact directly with the VMs to manage groups of
*
* This interface is highly experimental at this point. Testing is
* welcomed, but do not expect too much of it right now. Even the
*
* This interface is highly experimental at this point. Testing is
* welcomed, but do not expect too much of it right now. Even the
* @brief This section describes the file structure of MSG
* (#msg_file_t) and the functions for managing it. It
* is based on POSIX functions.
* @brief This section describes the file structure of MSG
* (#msg_file_t) and the functions for managing it. It
* is based on POSIX functions.
@defgroup msg_trace_driven Trace-driven simulations
@ingroup MSG_API
@brief This section describes the functions allowing to build trace-driven simulations.
@defgroup msg_trace_driven Trace-driven simulations
@ingroup MSG_API
@brief This section describes the functions allowing to build trace-driven simulations.
This is very handy when you want to test an algorithm or protocol that
does nothing unless it receives some events from outside. For example,
a P2P protocol reacts to requests from the user, but does nothing if
This is very handy when you want to test an algorithm or protocol that
does nothing unless it receives some events from outside. For example,
a P2P protocol reacts to requests from the user, but does nothing if
In such situations, SimGrid allows to write your protocol in your C
file, and the events to react to in a separate text file. Declare a
function handling each of the events that you want to accept in your
trace files, register them using #MSG_action_register in your main,
and then use #MSG_action_trace_run to launch the simulation. You can
either have one trace file containing all your events, or a file per
In such situations, SimGrid allows to write your protocol in your C
file, and the events to react to in a separate text file. Declare a
function handling each of the events that you want to accept in your
trace files, register them using #MSG_action_register in your main,
and then use #MSG_action_trace_run to launch the simulation. You can
either have one trace file containing all your events, or a file per
This is the lua bindings of the \ref MSG_API interface.
\section lMSG_who Who should use this (and who shouldn't)
This is the lua bindings of the \ref MSG_API interface.
\section lMSG_who Who should use this (and who shouldn't)
If you want to use MSG to study your algorithm, but you don't want to
use the C language (using \ref MSG_API), then you should use some
bindings such as this one. The advantage of the lua bindings is that
If you want to use MSG to study your algorithm, but you don't want to
use the C language (using \ref MSG_API), then you should use some
bindings such as this one. The advantage of the lua bindings is that
lua modules implemented directly in C as we are using, there is no
ready to use reference documentation for this module. Even more than
for the other modules, you will have to dig into the source code of
lua modules implemented directly in C as we are using, there is no
ready to use reference documentation for this module. Even more than
for the other modules, you will have to dig into the source code of
- \ref MSG_ex_master_slave_lua
- \ref MSG_ex_master_slave_lua_bypass
- Also, the lua version of the Chord example (in the source tree)
- \ref MSG_ex_master_slave_lua
- \ref MSG_ex_master_slave_lua_bypass
- Also, the lua version of the Chord example (in the source tree)
We don't remove them because the ability to run old scientific
code is something important to us. But these functionalities are
We don't remove them because the ability to run old scientific
code is something important to us. But these functionalities are
To access these functions, you should define the relevant option
at configuration time in ccmake.
*/
To access these functions, you should define the relevant option
at configuration time in ccmake.
*/
This function is the core of the simulation and is divided only into 3 parts
thanks to MSG_create_environment() and MSG_launch_application().
This function is the core of the simulation and is divided only into 3 parts
thanks to MSG_create_environment() and MSG_launch_application().
Its arguments are:
- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
- <i>application_file</i>: the name of a file containing a valid surfxml application description
Its arguments are:
- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
- <i>application_file</i>: the name of a file containing a valid surfxml application description
This function has to be assigned to a m_process_t that will behave as
the master. It should not be called directly but either given as a
parameter to #MSG_process_create() or registered as a public function
through #MSG_function_register() and then automatically assigned to a
process through #MSG_launch_application().
This function has to be assigned to a m_process_t that will behave as
the master. It should not be called directly but either given as a
parameter to #MSG_process_create() or registered as a public function
through #MSG_function_register() and then automatically assigned to a
process through #MSG_launch_application().
C style arguments (argc/argv) are interpreted as:
- the number of tasks to distribute
- the computation size of each task
C style arguments (argc/argv) are interpreted as:
- the number of tasks to distribute
- the computation size of each task
This function has to be assigned to a #m_process_t that has to behave
as a slave. Just like the master fuction (described in \ref
MSG_ext_ms_master), it should not be called directly.
This function keeps waiting for tasks and executes them as it receives them.
This function has to be assigned to a #m_process_t that has to behave
as a slave. Just like the master fuction (described in \ref
MSG_ext_ms_master), it should not be called directly.
This function keeps waiting for tasks and executes them as it receives them.
This function has to be assigned to a #m_process_t that has to behave
as a forwarder. Just like the master function (described in \ref
MSG_ext_ms_master), it should not be called directly.
This function has to be assigned to a #m_process_t that has to behave
as a forwarder. Just like the master function (described in \ref
MSG_ext_ms_master), it should not be called directly.
This function is the core of the simulation and is divided only into 3 parts
thanks to MSG_create_environment() and MSG_launch_application().
This function is the core of the simulation and is divided only into 3 parts
thanks to MSG_create_environment() and MSG_launch_application().
Its arguments are:
- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
- <i>application_file</i>: the name of a file containing a valid surfxml application description
Its arguments are:
- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.
- <i>application_file</i>: the name of a file containing a valid surfxml application description
Simulation of a master-slave application using lua bindings
- \ref MSG_ext_ms_code_lua
- \ref MSG_ext_ms_master_lua
Simulation of a master-slave application using lua bindings
- \ref MSG_ext_ms_code_lua
- \ref MSG_ext_ms_master_lua
Lua style arguments (...) in for the master are interpreted as:
- the number of tasks to distribute
- the computation size of each task
Lua style arguments (...) in for the master are interpreted as:
- the number of tasks to distribute
- the computation size of each task
This function has to be assigned to a #m_process_t that has to behave as a slave.
This function keeps waiting for tasks and executes them as it receives them.
This function has to be assigned to a #m_process_t that has to behave as a slave.
This function keeps waiting for tasks and executes them as it receives them.
\until end_of_slave
\subsection MSG_ext_ms_core_lua Simulation core
in this section the core of the simulation which start by including the simgrid lib for bindings
: <i>require "simgrid" </i>
\until end_of_slave
\subsection MSG_ext_ms_core_lua Simulation core
in this section the core of the simulation which start by including the simgrid lib for bindings
: <i>require "simgrid" </i>
-
- -# Simulation settings : <i>simgrid.platform</i> creates a realistic
- environment
- -# Application deployment : create the processes on the right locations with
+
+ -# Simulation settings : <i>simgrid.platform</i> creates a realistic
+ environment
+ -# Application deployment : create the processes on the right locations with
Its arguments are:
- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
- <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
Its arguments are:
- <i>platform_file</i>: the name of a file containing an valid surfxml platform description.( first command line argument)
- <i>application_file</i>: the name of a file containing a valid surfxml application description ( second commande line argument )
Simulation of a master-slave application using lua bindings, Bypassing the XML parser
- \ref MSG_ext_ms_code_lua
- \ref MSG_ext_ms_master_lua
- \ref MSG_ext_ms_slave_lua
- \ref MSG_ext_ms_core_lua
Simulation of a master-slave application using lua bindings, Bypassing the XML parser
- \ref MSG_ext_ms_code_lua
- \ref MSG_ext_ms_master_lua
- \ref MSG_ext_ms_slave_lua
- \ref MSG_ext_ms_core_lua
Lua style arguments (...) in for the master are interpreted as:
- the number of tasks to distribute
- the computation size of each task
Lua style arguments (...) in for the master are interpreted as:
- the number of tasks to distribute
- the computation size of each task
This function has to be assigned to a #m_process_t that has to behave as a slave.
This function keeps waiting for tasks and executes them as it receives them.
This function has to be assigned to a #m_process_t that has to behave as a slave.
This function keeps waiting for tasks and executes them as it receives them.
\until end_of_slave
\subsection MSG_ext_ms_core_lua Simulation core
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.
: <i>require "simgrid" </i>
\until end_of_slave
\subsection MSG_ext_ms_core_lua Simulation core
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.
: <i>require "simgrid" </i>
-# Hosts : <i>simgrid.Host.new</i> instanciate a new host with an id, and power.
-# Links : <i>simgrid.Link.new</i> instanictae a new link that will require an id, bandwith and latency values.
-# Route : <i>simgrid.Route.new</i> define a route between two hosts specifying the links to use.
-# Hosts : <i>simgrid.Host.new</i> instanciate a new host with an id, and power.
-# Links : <i>simgrid.Link.new</i> instanictae a new link that will require an id, bandwith and latency values.
-# Route : <i>simgrid.Route.new</i> define a route between two hosts specifying the links to use.