MSG_comm_test(), MSG_comm_wait(), MSG_comm_waitall() and MSG_comm_waitany();
MSG_comm_destroy().
-There is even a specific example section on \ref msg_ex_asynchronous_communications.
+There is even a specific example section on \ref msg_ex_async .
\subsubsection faq_MIA_thread_synchronization How to synchronize my user processes?
The <b>intra-zone level</b> is naturally handled by the netzones. Each
netzone have to specify the routing algorithm it uses for that.
-@ref{FullZone} netzones have complete matrix where matrix(a,b)
+@ref simgrid::kernel::routing::FullZone "FullZone" netzones have complete matrix where matrix(a,b)
represents the full path (the list of links) between the hosts a and
-b. @ref{FloydZone} apply the Floyd-Warshall algorithm to compute the
-paths. @ref{ClusterZone} model classical switched or hub networks,
+b. @ref simgrid::kernel::routing::FloydZone "FloydZone" apply the Floyd-Warshall algorithm to compute the
+paths. @ref simgrid::kernel::routing::ClusterZone "ClusterZone" model classical switched or hub networks,
where each component is connected through a private link onto a common
backbone. Many other routing algorithms are provided to model the
classical needs, but you can naturally define your own routing if the
everywhere in S4U. This is an idiom where resources are automatically
managed through the context. Provided that you never manipulate
objects of type Foo directly but always FooPtr references (which are
-[boost::intrusive_ptr](http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html)<Foo>),
+[boost::intrusive_ptr](http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html)<Foo>),
you will never have to explicitely release the resource that you use
nor to free the memory of unused objects.
make
@endverbatim
-\warn
+\warning
Again, make sure that SMPI_PRETEND_CC is not set when you actually
compile your application. It is just a work-around for some configure-scripts
and replaces some internals by "return 0;". Your simulation will not
- Data structures
- \ref XBT_dynar
- \ref XBT_dict
- - \ref XBT_set
- Data are associated to both an ID (0(1) search) and a name
- \ref XBT_fifo
- \ref XBT_swag
- \ref XBT_heap
simulate the behavior of most of the existing MPI libraries. The \b smpi/coll-selector item can be used
to use the decision logic of either OpenMPI or MPICH libraries (values: ompi or mpich, by default SMPI
uses naive version of collective operations). Each collective operation can be manually selected with a
-\b smpi/collective_name:algo_name. Available algorithms are listed in \ref SMPI_collective_algorithms .
+\b smpi/collective_name:algo_name. Available algorithms are listed in \ref SMPI_use_colls .
\subsection options_model_smpi_iprobe smpi/iprobe: Inject constant times for calls to MPI_Iprobe
\subsection pf_As Platform: The <AS> tag
-The concept of an AS was already outlined above (Section \ref pf_basics);
-recall that the AS is so important because it groups other resources (such
-as routers/hosts) together (in fact, these resources must be contained by
-an AS).
+For historical reasons, the XML files use the expression AS for
+NetZones. Netzones are very important because they group other resources (such
+as routers/hosts) together (in fact, any such resource must be
+contained in a NetZone).
Available attributes :
loopback_bw | no | int | Bandwidth for loopback (if any). See <b>link</b> section for syntax/details. If loopback_bw and loopback_lat (see below) attributes are omitted, no loopback link is created and all intra-node communication will use the main network link of the node. Loopback link is a \ref pf_sharing_policy_fatpipe "\b FATPIPE".
loopback_lat | no | int | Latency for loopback (if any). See <b>link</b> section for syntax/details. See loopback_bw for more info.
topology | no | FLAT\|TORUS\|FAT_TREE\|DRAGONFLY (default: FLAT) | Network topology to use. SimGrid currently supports FLAT (with or without backbone, as described before), <a href="http://en.wikipedia.org/wiki/Torus_interconnect">TORUS </a>, FAT_TREE, and DRAGONFLY attributes for this tag.
-topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. For fat trees, refer to \ref simgrid::kernel::routing::AsClusterFatTree "AsClusterFatTree documentation". For dragonfly, refer to \ref simgrid::kernel::routing::AsClusterDragonfly "AsClusterDragonfly documentation".
+topo_parameters | no | string | Specific parameters to pass for the topology defined in the topology tag. For torus networks, comma-separated list of the number of nodes in each dimension of the torus. Please refer to the specific documentation for \ref simgrid::kernel::routing::FatTreeZone "FatTree NetZone", \ref simgrid::kernel::routing::DragonflyZone "Dragonfly NetZone".
the router name is defined as the resulting String in the following
\subsubsection pf_peer The <peer> tag
-This tag represents a peer, as in Peer-to-Peer (P2P) networks. However, internally,
-SimGrid transforms a peer into an AS (similar to Cluster). Hence, this tag
-is virtually only a shortcut that comes with some pre-defined resources
-and values. These are:
+This tag represents a peer, as in Peer-to-Peer (P2P) networks. This
+can only be used in Vivaldi NetZones. It creates the following
+resources to the NetZone:
-\li A tiny AS whose routing type is cluster is created
\li A host
\li Two links: One for download and one for upload. This is
convenient to use and simulate stuff under the last mile model (e.g., ADSL peers).
\li It connects the two links to the host
-\li It creates a router (a gateway) that serves as an entry point for this peer zone.
- This router has coordinates.
#### Attributes ####
--------------- | --------- | ------ | -----------
id | yes | string | The identifier of the peer. Facilitates referring to this peer.
speed | yes | int | See the description of the ``host`` tag for this attribute
-bw_in | yes | int | Bandwidth downstream
-bw_out | yes | int | Bandwidth upstream
+bw_in | yes | int | Bandwidth of the private downstream link
+bw_out | yes | int | Bandwidth of the private upstream link
lat | yes | double | Latency for both up- and downstream, in seconds.
coordinates | no | string | Coordinates of the gateway for this peer. Example value: 12.8 14.4 6.4
sharing_policy | no | SHARED\|FULLDUPLEX (default: FULLDUPLEX) | Sharing policy for links. See <b>link</b> description for details.
availability_file| no | string | Availability file for the peer. Same as host availability file. See <b>host</b> description for details.
state_file | no | string | State file for the peer. Same as host state file. See <b>host</b> description for details.
-Internally, SimGrid transforms any ``\<peer/\>`` construct such as
-\verbatim
-<peer id="FOO"
- coordinates="12.8 14.4 6.4"
- speed="1.5Gf"
- bw_in="2.25GBps"
- bw_out="2.25GBps"
- lat="500us" />
-\endverbatim
-into an ``\<AS\>`` (see Sections \ref pf_basics and \ref pf_As). In fact, this example of the ``\<peer/\>`` tag
-is completely equivalent to the following declaration:
-
-\verbatim
-<AS id="as_FOO" routing="Cluster">
- <host id="peer_FOO" speed="1.5Gf"/>
- <link id="link_FOO_UP" bandwidth="2.25GBps" latency="500us"/>
- <link id="link_FOO_DOWN" bandwidth="2.25GBps" latency="500us"/>
- <router id="router_FOO" coordinates="25.5 9.4 1.4"/>
- <host_link id="peer_FOO" up="link_FOO_UP" down="link_FOO_DOWN"/>
-</AS>
-\endverbatim
-
-
\subsection pf_ne Network equipments: links and routers
There are two tags at all times available to represent network entities and
For more information on how to use the [Vivaldi Coordinates](https://en.wikipedia.org/wiki/Vivaldi_coordinates),
see also Section \ref pf_P2P_tags "P2P tags".
-For documentation on how to activate this model (as some initialization must be done
-in the simulator), see Section \ref options_model_network_coord "Activating Coordinate Based Routing".
-
Note that it is possible to combine the Vivaldi routing model with other routing models;
an example can be found in the file \c examples/platforms/cloud.xml. This
-examples models an AS using Vivaldi that contains other ASes that use different
+examples models a NetZone using Vivaldi that contains other NetZones that use different
routing models.
#### Example platform files ####
XBT_log, \ref XBT_ex and \ref XBT_config.
XBT also encompass the following convenient C data structures:
-\ref XBT_dynar, \ref XBT_fifo, \ref XBT_dict, \ref XBT_heap, \ref XBT_set and
+\ref XBT_dynar, \ref XBT_fifo, \ref XBT_dict, \ref XBT_heap, and
\ref XBT_swag. The code is being migrated in C++ so you should probably want
to use standard C++ containers instead of them if possible.
@section msg_ex_async Asynchronous communications
In addition to the fully documented example of @ref
-msg_ex_asynchronous_communications, there are several other examples
+MSG_ex_asynchronous_communications, there are several other examples
shipped in the archive:
- <b>Basic asynchronous communications</b>.
* @{
*/
-/** @brief Simulation Agent (see \ref s4u_actor)*/
+/** @brief Simulation Agent */
XBT_PUBLIC_CLASS Actor {
friend Mailbox;
friend simgrid::simix::ActorImpl;
*
* Used to simulate the time it takes to access to a file, but does not really store any information.
*
- * They are located on @link{simgrid::s4u::Storage} that are accessed from a given @link{simgrid::s4u::Host} through mountpoints.
+ * They are located on @ref simgrid::s4u::Storage that are accessed from a given @ref simgrid::s4u::Host through mountpoints.
* For now, you cannot change the mountpoints programatically, and must declare them from your platform file.
*/
XBT_PUBLIC_CLASS File {
* An host represents some physical resource with computing and networking capabilities.
*
* All hosts are automatically created during the call of the method
- * @link{simgrid::s4u::Engine::loadPlatform()}.
+ * @ref simgrid::s4u::Engine::loadPlatform().
* You cannot create a host yourself.
*
* You can retrieve a particular host using simgrid::s4u::Host::byName()
* The path between components is computed each time you request it,
* using the Dijkstra algorithm. A cache can be used to reduce the computation.
*
- * This result in rather small platform file, very fast initialization, and intermediate memory requirements
- * (somewhere between the one of @DijkstraZone and the one of @FullZone).
+ * This result in rather small platform file, very fast initialization, and very low memory requirements, but somehow long path resolution times.
*/
class XBT_PRIVATE DijkstraZone : public RoutedZone {
public:
class XBT_PRIVATE FatTreeLink;
-/** \brief A node in a fat tree (@ref AsClusterFatTree).
+/** \brief A node in a fat tree (@ref FatTreeZone).
* A FatTreeNode can either be a switch or a processing node. Switches are
* identified by a negative ID. This class is closely related to fat
*/
FatTreeNode(sg_platf_cluster_cbarg_t cluster, int id, int level, int position);
};
-/** \brief Link in a fat tree (@ref AsClusterFatTree).
+/** \brief Link in a fat tree (@ref FatTreeZone).
*
* Represents a single, duplex link in a fat tree. This is necessary to have a tree.
* It is equivalent to a physical link.
* Finding the path between two nodes is rather complex because we navigate a hierarchy of netzones, each of them
* being a full network. In addition, the routing can declare shortcuts (called bypasses), either within a NetZone
* at the route level or directly between NetZones. Also, each NetZone can use a differing routing algorithm, depending
- * on its class. @ref{FullZone} have a full matrix giving explicitly the path between any pair of their
- * contained nodes, while @ref{DijkstraZone} or @ref{FloydZone} rely on a shortest path algorithm. @ref{VivaldiZone}
+ * on its class. @ref FullZone have a full matrix giving explicitly the path between any pair of their
+ * contained nodes, while @ref DijkstraZone or @ref FloydZone rely on a shortest path algorithm. @ref VivaldiZone
* does not even have any link but only use only coordinate information to compute the latency.
*
* So NetZoneImpl::getGlobalRoute builds the path recursively asking its specific information to each traversed NetZone
/** Write data to a process memory
*
- * @param process the process
- * @param local local memory address (source)
- * @param remote target process memory address (target)
- * @param len data size
+ * @param buffer local memory address (source)
+ * @param len data size
+ * @param address target process memory address (target)
*/
void Process::write_bytes(const void* buffer, size_t len, RemotePtr<void> address)
{
/** Check whether two blocks are known to be matching
*
- * @param state State used
* @param b1 Block of state 1
* @param b2 Block of state 2
* @return if the blocks are known to be matching
/** Check whether two fragments are known to be matching
*
- * @param state State used
* @param b1 Block of state 1
* @param f1 Fragment of state 1
* @param b2 Block of state 2
/** @brief Restore a region from a snapshot
*
- * @param reg Target region
+ * @param region Target region
*/
static void restore(mc_mem_region_t region)
{
* A variable may be defined only from a given value of IP.
*
* \param var Variable description
- * \param frame Scope description
+ * \param scope Scope description
* \param ip Instruction pointer
* \return true if the variable is valid
* */
return result;
}
-/** \brief Find the default lower bound for a given language
+/** @brief Find the default lower bound for a given language
*
* The default lower bound of an array (when DW_TAG_lower_bound
* is missing) depends on the language of the compilation unit.
*
- * \param lang Language of the compilation unit (values defined in the DWARF spec)
- * \return Default lower bound of an array in this compilation unit
+ * @param lang Language of the compilation unit (values defined in the DWARF spec)
+ * @return Default lower bound of an array in this compilation unit
* */
static uint64_t MC_dwarf_default_lower_bound(int lang)
{
/**
* \brief This function is called by SIMIX in kernel mode to copy the data of a comm.
- * \param comm the comm
+ * \param synchro the comm
* \param buff the data copied
* \param buff_size size of the buffer
*/
/** \ingroup m_vm_management
* \brief Get the parameters of a given host
*
- * \param host a host
+ * \param vm the vm you are interested into
* \param params a prameter object
*/
void MSG_vm_get_params(msg_vm_t vm, vm_params_t params)
* \brief Find a route toward another host
*
* \param dest [IN] where to
- * \param route [OUT] where to store the list of links (must exist, cannot be nullptr).
+ * \param links [OUT] where to store the list of links (must exist, cannot be nullptr).
* \param latency [OUT] where to store the latency experienced on the path (or nullptr if not interested)
* It is the caller responsibility to initialize latency to 0 (we add to provided route)
- * \pre route!=nullptr
+ * \pre links!=nullptr
*
* walk through the routing components tree and find a route between hosts
* by calling each "get_route" function in each routing component.
*
* \param task the task you want to schedule
* \param host_count number of hosts on which the task will be executed
- * \param workstation_list the hosts on which the task will be executed
+ * \param host_list the hosts on which the task will be executed
* \param flops_amount computation amount for each hosts (i.e., an array of host_count doubles)
* \param bytes_amount communication amount between each pair of hosts (i.e., a matrix of host_count*host_count doubles)
* \param rate task execution speed rate
/** @brief Ask another process to raise the given exception
*
+ * @param process The process that should raise that exception
* @param cat category of exception
* @param value value associated to the exception
* @param msg string information associated to the exception
* \param code the main function of the process
* \param data a pointer to any data one may want to attach to the new object. It is for user-level information and can be nullptr.
* It can be retrieved with the function \ref simcall_process_get_data.
- * \param hostname name of the host where the new agent is executed.
+ * \param host where the new agent is executed.
* \param kill_time time when the process is killed
* \param argc first argument passed to \a code
* \param argv second argument passed to \a code
* \brief Set the category of an synchro.
*
* This functions changes the category only. It calls a surf function.
- * \param execution The execution synchro
+ * \param synchro The execution synchro
* \param category The tracing category
*/
void simcall_set_category(smx_activity_t synchro, const char *category)
*
* Set the date to execute the function on the surf.
* \param date Date to execute function
- * \param function Function to be executed
+ * \param callback Function to be executed
* \param arg Parameters of the function
*
*/
/**
- * \brief Copy the communication data from the sender's buffer to the receiver's one
- * \param comm The communication
+ * @brief Copy the communication data from the sender's buffer to the receiver's one
+ * @param synchro The communication
*/
void SIMIX_comm_copy_data(smx_activity_t synchro)
{
* error message in that case.
*
* Yeah, that's terribly hackish, but it works. A better solution should be dealed with in flexml
- * directly: a command line flag could instruct it to do the correct thing when #include is encountered
+ * directly: a command line flag could instruct it to do the correct thing when the include directive is encountered
* on a line. One day maybe, if the maya allow it.
*/
int ETag_surfxml_include_state()
