Choosing the Platform Models
............................
-SimGrid comes with several network, CPU and storage models built in,
+SimGrid comes with several network, CPU and disk models built in,
and you can change the used model at runtime by changing the passed
configuration. The three main configuration items are given below.
For each of these items, passing the special ``help`` value gives you
S4U interface to express their computation, communication, disk usage
and other |Activities|_, so that they get reflected within the
simulator. These activities take place on **Resources** (|Hosts|_,
-|Links|_, |Storages|_). SimGrid predicts the time taken by each
+|Links|_, |Disks|_). SimGrid predicts the time taken by each
activity and orchestrates accordingly the actors waiting for the
completion of these activities.
.. |Links| replace:: **Links**
.. _Links: app_s4u.html#s4u-link
-.. |Storages| replace:: **Storages**
-.. _Storages: app_s4u.html#s4u-storage
+.. |Disks| replace:: **Disks**
+.. _Disks: app_s4u.html#s4u-disk
.. |VirtualMachines| replace:: **VirtualMachines**
.. _VirtualMachines: app_s4u.html#s4u-virtualmachine
A host is the computing resource on which an actor can run. See :cpp:class:`simgrid::s4u::Host`.
**Parent tags:** :ref:`pf_tag_zone` (only leaf zones, i.e., zones containing neither inner zones nor clusters) |br|
-**Children tags:** :ref:`pf_tag_mount`, :ref:`pf_tag_prop`, :ref:`pf_tag_storage` |br|
+**Children tags:** :ref:`pf_tag_mount`, :ref:`pf_tag_prop`, :ref:`pf_tag_disk` |br|
**Attributes:**
:``id``: Host name.
- Cluster: this is a zone, see below.
- Host: :cpp:func:`simgrid::s4u::Host::get_property` or :cpp:func:`MSG_host_get_property_value`
- Link: :cpp:func:`simgrid::s4u::Link::get_property`
-- Storage: :cpp:func:`simgrid::s4u::Storage::get_property` or :cpp:func:`MSG_storage_get_property_value`
+- Disk: :cpp:func:`simgrid::s4u::Disk::get_property`
+- Storage :cpp:func:`MSG_storage_get_property_value` (deprecated)
- Zone: :cpp:func:`simgrid::s4u::Zone::get_property` of :cpp:func:`MSG_zone_get_property_value`
**Parent tags:** :ref:`pf_tag_actor`, :ref:`pf_tag_config`, :ref:`pf_tag_cluster`, :ref:`pf_tag_host`,
-:ref:`pf_tag_link`, :ref:`pf_tag_storage`, :ref:`pf_tag_zone` |br|
+:ref:`pf_tag_link`, :ref:`pf_tag_disk`,:ref:`pf_tag_storage` (deprecated), :ref:`pf_tag_zone` |br|
**Children tags:** none |br|
**Attributes:**
break the routes that are longer than 1 hop.
**Parent tags:** :ref:`pf_tag_zone` (only leaf zones, i.e., zones containing neither inner zones nor clusters) |br|
-**Children tags:** :ref:`pf_tag_prop`, :ref:`pf_tag_storage` |br|
**Attributes:**
:``id``: Router name.
:ref:`communication <API_s4u_Comm>`, :ref:`disk usage <API_s4u_Io>`,
and other |API_s4u_Activities|_, so that they get reflected within the
simulator. These activities take place on resources such as |API_s4u_Hosts|_,
-|API_s4u_Links|_ and |API_s4u_Storages|_. SimGrid predicts the time taken by each
+|API_s4u_Links|_ and |API_s4u_Disks|_. SimGrid predicts the time taken by each
activity and orchestrates the actors accordingly, waiting for the
completion of these activities.
- **Platform Elements**
+ - :ref:`class s4u::Disk <API_s4u_Disk>`
+ Resource on which actors can write and read data.
- :ref:`class s4u::Host <API_s4u_Host>`:
Actor location, providing computational power.
- :ref:`class s4u::Link <API_s4u_Link>`
Interconnecting hosts.
- :ref:`class s4u::NetZone <API_s4u_NetZone>`:
Sub-region of the platform, containing resources (Hosts, Links, etc).
- - :ref:`class s4u::Storage <API_s4u_Storage>`
- Resource on which actors can write and read data.
- :ref:`class s4u::VirtualMachine <API_s4u_VirtualMachine>`:
Execution containers that can be moved between Hosts.
- :ref:`class s4u::Exec <API_s4u_Exec>`
Computation activity, started on Host and consuming CPU resources.
- :ref:`class s4u::Io <API_s4u_Io>`
- I/O activity, started on and consumming Storages.
+ I/O activity, started on and consumming disks.
- **Synchronization Mechanisms**: Classical IPC that actors can use
.. |API_s4u_Links| replace:: **Links**
.. _API_s4u_Links: #s4u-link
-.. |API_s4u_Storages| replace:: **Storages**
-.. _API_s4u_Storages: #s4u-storage
+.. |API_s4u_Disks| replace:: **Disks**
+.. _API_s4u_Disks: #s4u-disk
.. |API_s4u_VirtualMachine| replace:: **VirtualMachines**
:cpp:func:`s4u::Mailbox::put_async() <simgrid::s4u::Mailbox::put_async>` and
:cpp:func:`s4u::Mailbox::get_async() <simgrid::s4u::Mailbox::get_async>`.
- :ref:`s4u::IoPtr <API_s4u_Io>` are created with
- :cpp:func:`s4u::Storage::read_async() <simgrid::s4u::Storage::read_async>` and
- :cpp:func:`s4u::Storage::write_async() <simgrid::s4u::Storage::write_async>`.
+ :cpp:func:`s4u::Disk::read_async() <simgrid::s4u::Disk::read_async>` and
+ :cpp:func:`s4u::Disk::write_async() <simgrid::s4u::Disk::write_async>`.
- :ref:`s4u::ExecPtr <API_s4u_Exec>` are created with
:cpp:func:`s4u::Host::exec_async() <simgrid::s4u::Host::exec_async>`.
- In the future, it will become possible to have asynchronous IPC
:protected-members:
:undoc-members:
+.. _API_s4u_Disk:
+
+============
+s4u::Disk
+============
+
+.. doxygenclass:: simgrid::s4u::Disk
+ :members:
+ :protected-members:
+ :undoc-members:
+
.. _API_s4u_Engine:
===========
:protected-members:
:undoc-members:
-.. _API_s4u_Storage:
-
-============
-s4u::Storage
-============
-
-.. doxygenclass:: simgrid::s4u::Storage
- :members:
- :protected-members:
- :undoc-members:
-
.. _API_s4u_VirtualMachine:
===================
as the full :ref:`XML reference guide <platform_reference>`.
-Any simulated platform must contain **basic elements**, such as hosts, links, storages, etc. SimGrid gives you a great
+Any simulated platform must contain **basic elements**, such as hosts, links, disks, etc. SimGrid gives you a great
liberty when defining the **routing of your platform**, i.e., the network path taken between each pair of hosts.
Finally, you may also describe an **experimental scenario**, with qualitative (e.g., bandwidth variations representing
an external load) and qualitative (e.g., representing how some elements fail and restart over time) changes.
----------------------
SimGrid provides two levels of abstraction to interact with the
-simulated storages. At the simplest level, you simply create read and
-write actions on the storage resources.
+simulated disks. At the simplest level, you simply create read and
+write actions on the disk resources.
- - **Access to raw storage devices:**
+ - **Access to raw disk devices:**
This example illustrates how to simply read and write data on a
- simulated storage resource.
- |br| `examples/s4u/io-storage-raw/s4u-io-storage-raw.cpp <https://framagit.org/simgrid/simgrid/tree/master/examples/s4u/io-storage-raw/s4u-io-storage-raw.cpp>`_
+ simulated disk resource.
+ |br| `examples/s4u/io-disk-raw/s4u-io-disk-raw.cpp <https://framagit.org/simgrid/simgrid/tree/master/examples/s4u/io-disk-raw/s4u-io-disk-raw.cpp>`_
The FileSystem plugin provides a more detailed view, with the
classical operations over files: open, move, unlink, and of course
virtual ~Disk() = default;
public:
- /** @brief Callback signal fired when a new Storage is created */
+ /** @brief Callback signal fired when a new Disk is created */
static xbt::signal<void(Disk&)> on_creation;
- /** @brief Callback signal fired when a Storage is destroyed */
+ /** @brief Callback signal fired when a Disk is destroyed */
static xbt::signal<void(Disk const&)> on_destruction;
- /** @brief Callback signal fired when a Storage's state changes */
+ /** @brief Callback signal fired when a Disk's state changes */
static xbt::signal<void(Disk const&)> on_state_change;
- /** @brief Retrieves the name of that storage as a C++ string */
+ /** @brief Retrieves the name of that disk as a C++ string */
std::string const& get_name() const { return name_; }
- /** @brief Retrieves the name of that storage as a C string */
+ /** @brief Retrieves the name of that disk as a C string */
const char* get_cname() const { return name_.c_str(); }
const std::unordered_map<std::string, std::string>* get_properties() const;
/** I/O Activity, representing the asynchronous disk access.
*
- * They are generated from Storage::io_init() or Storage::read() and Storage::write().
+ * They are generated from Disk::io_init(), Disk::read() Disk::read_async(), Disk::write() and Disk::write_async().
*/
class XBT_PUBLIC Io : public Activity {
