rather realistic simulations, but remains simple to use: most unpleasant
technical elements can be abstracted away rather easily. If you want to use the
C programming language, your are in the right section. If you prefer not to use
-this venerable but demanding language, please refer to the @ref MSG_Java, the
-@ref MSG_LUA, or the @ref MSG_Ruby (that are distributed separately).
+this venerable but demanding language, please refer to the @ref MSG_Java section.
If you think that MSG may not be the interface you need, please consider the
other user interfaces provided by SimGrid: If you want to use DAGs, have a look
- \ref msg_file_management
- \ref msg_task_usage
- \ref msg_VMs
+ - \ref msg_synchro
- \ref msg_trace_driven
- \ref MSG_examples
- - \ref msg_deprecated_functions
Also make sure to visit the page @ref MSG_examples.
* by a process to execute, communicate or otherwise handle some task.
*/
+/** @defgroup msg_synchro Explicit Synchronization Functions
+ * @ingroup MSG_API
+ * @brief This section describes several explicit synchronization
+ * mechanisms existing in MSG: semaphores (#msg_sem_t) and friends.
+ *
+ * In some situations, these things are very helpful to synchronize processes without message exchanges.
+ */
+
/** @defgroup msg_VMs VMs
* @ingroup MSG_API
* @brief This section describes the interface created to mimic IaaS clouds.
*
*/
+/** @defgroup msg_storage_management Storage Management Functions
+ * @ingroup MSG_API
+ * @brief This section describes the storage structure of MSG
+ * (#msg_storage_t) and the functions for managing it. It
+ * is based on POSIX functions.
+ */
+
/** @defgroup msg_file_management File Management Functions
* @ingroup MSG_API
* @brief This section describes the file structure of MSG
* is based on POSIX functions.
*/
-
/**
@defgroup msg_trace_driven Trace-driven simulations
@ingroup MSG_API
*/
-
-/**
-@defgroup MSG_LUA Lua bindings
-@ingroup MSG_API
-@brief Lua bindings to MSG (\ref MSG_API)
-
-@htmlonly <!-- DOXYGEN_NAVBAR_LABEL="LUA bindings" --> @endhtmlonly
-
-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. Just like the \ref MSG_Java, the advantage of the lua bindings is that they
-are distributed directly with the main archive (in contrary to Ruby bindings,
-that are distributed separately). Another advantage of lua is that there is
-almost no performance loss with regard to the C version (at least there
-shouldn't be any -- it is still to be precisely assessed).
-
-\section MSG_Lua_funct Lua offered functionnalities in MSG
-
-Almost all important features of the MSG interface are available from
-the lua bindings. Unfortunately, since doxygen does not support the
-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
-the examples to learn how to use it.
-
-\section Lua_examples Examples of lua MSG
-
- - \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)
- is a working non-trivial example of use of the lua bindings
-*/
-
/**
@defgroup MSG_examples MSG examples
@ingroup MSG_API
*/
-/**
-@defgroup msg_deprecated_functions MSG Deprecated
-@ingroup MSG_API
-@brief This section describes the deprecated functions. PLEASE STOP USING THEM.
-
-We don't remove them because the ability to run old scientific
-code is something important to us. But these functionalities are
-not actively supported anymore.
-
-To access these functions, you should define the relevant option
-at configuration time in ccmake.
- */
-