docs/source/app_s4u.rst

   1 .. _S4U_doc:
   2
   3 The S4U Interface
   4 #################
   5
   6 .. raw:: html
   7
   8    <object id="TOC" data="graphical-toc.svg" width="100%" type="image/svg+xml"></object>
   9    <script>
  10    window.onload=function() { // Wait for the SVG to be loaded before changing it
  11      var elem=document.querySelector("#TOC").contentDocument.getElementById("S4UBox")
  12      elem.style="opacity:0.93999999;fill:#ff0000;fill-opacity:0.1";
  13    }
  14    </script>
  15    <br/>
  16    <br/>
  17
  18 The S4U interface (SimGrid for you) mixes the full power of SimGrid
  19 with the full power of C++. This is the preferred interface to describe
  20 abstract algorithms in the domains of Cloud, P2P, HPC, IoT, and similar
  21 settings.
  22
  23 Since v3.20 (June 2018), S4U is definitely the way to go for long-term
  24 projects. It is feature complete, but may still evolve slightly in the
  25 future releases. It can already be used to do everything that can be
  26 done in SimGrid, but you may have to adapt your code in future
  27 releases. When this happens, compiling your code will produce
  28 deprecation warnings for 4 releases (one year) before the removal of
  29 the old symbols.
  30 If you want an API that will never ever evolve in the future, you
  31 should use the deprecated MSG API instead.
  32
  33 Main Concepts
  34 *************
  35
  36 A typical SimGrid simulation is composed of several |API_s4u_Actors|_, that
  37 execute user-provided functions. The actors have to explicitly use the
  38 S4U interface to express their :ref:`computation <API_s4u_Exec>`,
  39 :ref:`communication <API_s4u_Comm>`, :ref:`disk usage <API_s4u_Io>`,
  40 and other |API_s4u_Activities|_, so that they get reflected within the
  41 simulator. These activities take place on resources such as |API_s4u_Hosts|_,
  42 |API_s4u_Links|_ and |API_s4u_Storages|_. SimGrid predicts the time taken by each
  43 activity and orchestrates the actors accordingly, waiting for the
  44 completion of these activities.
  45
  46
  47 When **communicating**, data is not directly sent to other actors but
  48 posted onto a |API_s4u_Mailbox|_ that serves as a rendez-vous point between
  49 communicating actors. This means that you don't need to know who you
  50 are talking to, you just put your communication `Put` request in a
  51 mailbox, and it will be matched with a complementary `Get`
  52 request.  Alternatively, actors can interact through **classical
  53 synchronization mechanisms** such as |API_s4u_Barrier|_, |API_s4u_Semaphore|_,
  54 |API_s4u_Mutex|_ and |API_s4u_ConditionVariable|_.
  55
  56 Each actor is located on a simulated |API_s4u_Host|_. Each host is located
  57 itself in a |API_s4u_NetZone|_, that knows the networking path between one
  58 resource to another. Each NetZone is included in another one, forming
  59 a tree of NetZones which root zone contains the whole platform.
  60
  61 The :ref:`simgrid::s4u::this_actor <API_s4u_this_actor>` namespace
  62 provides many helper functions to simplify the code of actors.
  63
  64 - **Global Classes**
  65
  66   - :ref:`class s4u::Actor <API_s4u_Actor>`:
  67     Active entities executing your application.
  68   - :ref:`class s4u::Engine <API_s4u_Engine>`
  69     Simulation engine (singleton).
  70   - :ref:`class s4u::Mailbox <API_s4u_Mailbox>`
  71     Communication rendez-vous.
  72
  73 - **Platform Elements**
  74
  75   - :ref:`class s4u::Host <API_s4u_Host>`:
  76     Actor location, providing computational power.
  77   - :ref:`class s4u::Link <API_s4u_Link>`
  78     Interconnecting hosts.
  79   - :ref:`class s4u::NetZone <API_s4u_NetZone>`:
  80     Sub-region of the platform, containing resources (Hosts, Links, etc).
  81   - :ref:`class s4u::Storage <API_s4u_Storage>`
  82     Resource on which actors can write and read data.
  83   - :ref:`class s4u::VirtualMachine <API_s4u_VirtualMachine>`:
  84     Execution containers that can be moved between Hosts.
  85
  86 - **Activities** (:ref:`class s4u::Activity <API_s4u_Activity>`):
  87   The things that actors can do on resources
  88
  89   - :ref:`class s4u::Comm <API_s4u_Comm>`
  90     Communication activity, started on Mailboxes and consuming links.
  91   - :ref:`class s4u::Exec <API_s4u_Exec>`
  92     Computation activity, started on Host and consuming CPU resources.
  93   - :ref:`class s4u::Io <API_s4u_Io>`
  94     I/O activity, started on and consumming Storages.
  95
  96 - **Synchronization Mechanisms**: Classical IPC that actors can use
  97
  98   - :ref:`class s4u::Barrier <API_s4u_Barrier>`
  99   - :ref:`class s4u::ConditionVariable <API_s4u_ConditionVariable>`
 100   - :ref:`class s4u::Mutex <API_s4u_Mutex>`
 101   - :ref:`class s4u::Semaphore <API_s4u_Semaphore>`
 102
 103
 104 .. |API_s4u_Actors| replace:: **Actors**
 105 .. _API_s4u_Actors: #s4u-actor
 106
 107 .. |API_s4u_Activities| replace:: **Activities**
 108 .. _API_s4u_Activities: #s4u-activity
 109
 110 .. |API_s4u_Hosts| replace:: **Hosts**
 111 .. _API_s4u_Hosts: #s4u-host
 112
 113 .. |API_s4u_Links| replace:: **Links**
 114 .. _API_s4u_Links: #s4u-link
 115
 116 .. |API_s4u_Storages| replace:: **Storages**
 117 .. _API_s4u_Storages: #s4u-storage
 118
 119 .. |API_s4u_VirtualMachines| replace:: **VirtualMachines**
 120 .. _API_s4u_VirtualMachines: #s4u-virtualmachine
 121
 122 .. |API_s4u_Host| replace:: **Host**
 123
 124 .. |API_s4u_Mailbox| replace:: **Mailbox**
 125
 126 .. |API_s4u_Mailboxes| replace:: **Mailboxes**
 127 .. _API_s4u_Mailboxes: #s4u-mailbox
 128
 129 .. |API_s4u_NetZone| replace:: **NetZone**
 130
 131 .. |API_s4u_Barrier| replace:: **Barrier**
 132
 133 .. |API_s4u_Semaphore| replace:: **Semaphore**
 134
 135 .. |API_s4u_ConditionVariable| replace:: **ConditionVariable**
 136
 137 .. |API_s4u_Mutex| replace:: **Mutex**
 138
 139 .. THE EXAMPLES
 140
 141 .. include:: ../../examples/s4u/README.rst
 142
 143 Activities
 144 **********
 145
 146 Activities represent the actions that consume a resource, such as a
 147 :ref:`s4u::Comm <API_s4u_Comm>` that consumes the *transmiting power* of
 148 :ref:`s4u::Link <API_s4u_Link>` resources.
 149
 150 =======================
 151 Asynchronous Activities
 152 =======================
 153
 154 Every activity can be either **blocking** or **asynchronous**. For
 155 example, :cpp:func:`s4u::Mailbox::put() <simgrid::s4u::Mailbox::put>`
 156 and :cpp:func:`s4u::Mailbox::get() <simgrid::s4u::Mailbox::get>`
 157 create blocking communications: the actor is blocked until the
 158 completion of that communication. Asynchronous communications do not
 159 block the actor during their execution but progress on their own.
 160
 161 Once your asynchronous activity is started, you can test for its
 162 completion using :cpp:func:`s4u::Activity::test() <simgrid::s4u::Activity::test>`.
 163 This function returns ``true`` if the activity completed already.
 164 You can also use :cpp:func:`s4u::Activity::wait() <simgrid::s4u::Activity::wait>`
 165 to block until the completion of the activity. To wait for at most a given amount of time,
 166 use  :cpp:func:`s4u::Activity::wait_for() <simgrid::s4u::Activity::wait_for>`.
 167 Finally, to wait at most until a specified time limit, use
 168 :cpp:func:`s4u::Activity::wait_until() <simgrid::s4u::Activity::wait_until>`.
 169
 170 .. todo::
 171
 172    wait_for and wait_until are currently not implemented for Exec and Io activities.
 173
 174 Every kind of activities can be asynchronous:
 175
 176   - :ref:`s4u::CommPtr <API_s4u_Comm>` are created with
 177     :cpp:func:`s4u::Mailbox::put_async() <simgrid::s4u::Mailbox::put_async>` and
 178     :cpp:func:`s4u::Mailbox::get_async() <simgrid::s4u::Mailbox::get_async>`.
 179   - :ref:`s4u::IoPtr <API_s4u_Io>` are created with
 180     :cpp:func:`s4u::Storage::read_async() <simgrid::s4u::Storage::read_async>` and
 181     :cpp:func:`s4u::Storage::write_async() <simgrid::s4u::Storage::write_async>`.
 182   - :ref:`s4u::ExecPtr <API_s4u_Exec>` are created with
 183     :cpp:func:`s4u::Host::exec_async() <simgrid::s4u::Host::exec_async>`.
 184   - In the future, it will become possible to have asynchronous IPC
 185     such as asynchronous mutex lock requests.
 186
 187 The following example shows how to have several concurrent
 188 communications ongoing.  First, you have to declare a vector in which
 189 we will store the ongoing communications. It is also useful to have a
 190 vector of mailboxes.
 191
 192 .. literalinclude:: ../../examples/s4u/async-waitall/s4u-async-waitall.cpp
 193    :language: c++
 194    :start-after: init-begin
 195    :end-before: init-end
 196    :dedent: 4
 197
 198 Then, you start all the communications that should occur concurrently with
 199 :cpp:func:`s4u::Mailbox::put_async() <simgrid::s4u::Mailbox::put_async>`.
 200 Finally, the actor waits for the completion of all of them at once
 201 with
 202 :cpp:func:`s4u::Comm::wait_all() <simgrid::s4u::Comm::wait_all>`.
 203
 204 .. literalinclude:: ../../examples/s4u/async-waitall/s4u-async-waitall.cpp
 205    :language: c++
 206    :start-after: put-begin
 207    :end-before: put-end
 208    :dedent: 4
 209
 210
 211 =====================
 212 Activities Life cycle
 213 =====================
 214
 215 Sometimes, you want to change the setting of an activity before it even starts.
 216
 217 .. todo:: write this section
 218
 219 .. _s4u_mailbox:
 220
 221 Mailboxes
 222 *********
 223
 224 Please also refer to the :ref:`API reference for s4u::Mailbox
 225 <API_s4u_Mailbox>`.
 226
 227 ===================
 228 What are Mailboxes?
 229 ===================
 230
 231 |API_s4u_Mailboxes|_ are rendez-vous points for network communications,
 232 similar to URLs on which you could post and retrieve data. Actually,
 233 the mailboxes are not involved in the communication once it starts,
 234 but only to find the contact with which you want to communicate.
 235
 236 They are similar to many common things: The phone number, which allows
 237 the caller to find the receiver. The twitter hashtag, which help
 238 senders and receivers to find each others. In TCP, the pair
 239 ``{host name, host port}`` to which you can connect to find your peer.
 240 In HTTP, URLs through which the clients can connect to the servers.
 241 In ZeroMQ, the queues are used to match senders and receivers.
 242
 243 One big difference with most of these systems is that no actor is the
 244 exclusive owner of a mailbox, neither in sending nor in receiving.
 245 Many actors can send into and/or receive from the same mailbox.  TCP
 246 socket ports for example are shared on the sender side but exclusive
 247 on the receiver side (only one process can receive from a given socket
 248 at a given point of time).
 249
 250 A big difference with TCP sockets or MPI communications is that
 251 communications do not start right away after a
 252 :cpp:func:`Mailbox::put() <simgrid::s4u::Mailbox::put()>`, but wait
 253 for the corresponding :cpp:func:`Mailbox::get() <simgrid::s4u::Mailbox::get()>`.
 254 You can change this by :ref:`declaring a receiving actor <s4u_receiving_actor>`.
 255
 256 A big difference with twitter hashtags is that SimGrid does not
 257 offer easy support to broadcast a given message to many
 258 receivers. So that would be like a twitter tag where each message
 259 is consumed by the first receiver.
 260
 261 A big difference with the ZeroMQ queues is that you cannot filter
 262 on the data you want to get from the mailbox. To model such settings
 263 in SimGrid, you'd have one mailbox per potential topic, and subscribe
 264 to each topic individually with a
 265 :cpp:func:`get_async() <simgrid::s4u::Mailbox::get_async()>` on each mailbox.
 266 Then, use :cpp:func:`Comm::wait_any() <simgrid::s4u::Comm::wait_any()>`
 267 to get the first message on any of the mailbox you are subscribed onto.
 268
 269 The mailboxes are not located on the network, and you can access
 270 them without any latency. The network delay are only related to the
 271 location of the sender and receiver once the match between them is
 272 done on the mailbox. This is just like the phone number that you
 273 can use locally, and the geographical distance only comes into play
 274 once you start the communication by dialing this number.
 275
 276 =====================
 277 How to use Mailboxes?
 278 =====================
 279
 280 You can retrieve any existing mailbox from its name (which is a
 281 unique string, just like a twitter tag). This results in a
 282 versatile mechanism that can be used to build many different
 283 situations.
 284
 285 To model classical socket communications, use "hostname:port" as
 286 mailbox names, and make sure that only one actor reads into a given
 287 mailbox. This does not make it easy to build a perfectly realistic
 288 model of the TCP sockets, but in most cases, this system is too
 289 cumbersome for your simulations anyway. You probably want something
 290 simpler, that turns our to be easy to build with the mailboxes.
 291
 292 Many SimGrid examples use a sort of yellow page system where the
 293 mailbox names are the name of the service (such as "worker",
 294 "master" or "reducer"). That way, you don't have to know where your
 295 peer is located to contact it. You don't even need its name. Its
 296 function is enough for that. This also gives you some sort of load
 297 balancing for free if more than one actor pulls from the mailbox:
 298 the first actor that can deal with the request will handle it.
 299
 300 =========================================
 301 How put() and get() Requests are Matched?
 302 =========================================
 303
 304 The matching algorithm simple: first come, first serve. When a new
 305 send arrives, it matches the oldest enqueued receive. If no receive is
 306 currently enqueued, then the incoming send is enqueued. As you can
 307 see, the mailbox cannot contain both send and receive requests: all
 308 enqueued requests must be of the same sort.
 309
 310 .. _s4u_receiving_actor:
 311
 312 ===========================
 313 Declaring a Receiving Actor
 314 ===========================
 315
 316 The last twist is that by default in the simulator, the data starts
 317 to be exchanged only when both the sender and the receiver are
 318 declared (it waits until both :cpp:func:`put() <simgrid::s4u::Mailbox::put()>`
 319 and :cpp:func:`get() <simgrid::s4u::Mailbox::get()>` are posted).
 320 In TCP, since you establish connexions beforehand, the data starts to
 321 flow as soon as the sender posts it, even if the receiver did not post
 322 its :cpp:func:`recv() <simgrid::s4u::Mailbox::recv()>` yet.
 323
 324 To model this in SimGrid, you can declare a specific receiver to a
 325 given mailbox (with the function
 326 :cpp:func:`set_receiver() <simgrid::s4u::Mailbox::set_receiver()>`).
 327 That way, any :cpp:func:`put() <simgrid::s4u::Mailbox::put()>`
 328 posted to that mailbox will start as soon as possible, and the data
 329 will already be there on the receiver host when the receiver actor
 330 posts its :cpp:func:`get() <simgrid::s4u::Mailbox::get()>`
 331
 332 Memory Management
 333 *****************
 334
 335 For sake of simplicity, we use `RAII
 336 <https://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization>`_
 337 everywhere in S4U. This is an idiom where resources are automatically
 338 managed through the context. Provided that you never manipulate
 339 objects of type Foo directly but always FooPtr references (which are
 340 defined as `boost::intrusive_ptr
 341 <http://www.boost.org/doc/libs/1_61_0/libs/smart_ptr/intrusive_ptr.html>`_
 342 <Foo>), you will never have to explicitely release the resource that
 343 you use nor to free the memory of unused objects.
 344
 345 Here is a little example:
 346
 347 .. code-block:: cpp
 348
 349    void myFunc()
 350    {
 351      simgrid::s4u::MutexPtr mutex = simgrid::s4u::Mutex::create(); // Too bad we cannot use `new`
 352
 353      mutex->lock();   // use the mutex as a simple reference
 354      //  bla bla
 355      mutex->unlock();
 356
 357    } // The mutex gets automatically freed because the only existing reference gets out of scope
 358
 359 API Reference
 360 *************
 361
 362 .. _API_s4u_this_actor:
 363
 364 =========================
 365 namespace s4u::this_actor
 366 =========================
 367
 368 .. doxygennamespace:: simgrid::s4u::this_actor
 369 .. _API_s4u_Activity:
 370
 371 =============
 372 s4u::Activity
 373 =============
 374
 375 .. doxygenclass:: simgrid::s4u::Activity
 376    :members:
 377    :protected-members:
 378    :undoc-members:
 379
 380 .. _API_s4u_Actor:
 381
 382 ==========
 383 s4u::Actor
 384 ==========
 385
 386 .. doxygentypedef:: ActorPtr
 387
 388 .. doxygenclass:: simgrid::s4u::Actor
 389    :members:
 390    :protected-members:
 391    :undoc-members:
 392
 393 .. _API_s4u_Barrier:
 394
 395 ============
 396 s4u::Barrier
 397 ============
 398
 399 .. doxygentypedef:: BarrierPtr
 400
 401 .. doxygenclass:: simgrid::s4u::Barrier
 402    :members:
 403    :protected-members:
 404    :undoc-members:
 405
 406 .. _API_s4u_Comm:
 407
 408 =========
 409 s4u::Comm
 410 =========
 411
 412 .. doxygentypedef:: CommPtr
 413
 414 .. doxygenclass:: simgrid::s4u::Comm
 415    :members:
 416    :protected-members:
 417    :undoc-members:
 418
 419 .. _API_s4u_ConditionVariable:
 420
 421 ======================
 422 s4u::ConditionVariable
 423 ======================
 424
 425 .. doxygentypedef:: ConditionVariablePtr
 426
 427 .. doxygenclass:: simgrid::s4u::ConditionVariable
 428    :members:
 429    :protected-members:
 430    :undoc-members:
 431
 432 .. _API_s4u_Engine:
 433
 434 ===========
 435 s4u::Engine
 436 ===========
 437
 438 .. doxygenclass:: simgrid::s4u::Engine
 439    :members:
 440    :protected-members:
 441    :undoc-members:
 442
 443 .. _API_s4u_Exec:
 444
 445 =========
 446 s4u::Exec
 447 =========
 448
 449 .. doxygentypedef:: ExecPtr
 450
 451 .. doxygenclass:: simgrid::s4u::Exec
 452    :members:
 453    :protected-members:
 454    :undoc-members:
 455
 456 .. _API_s4u_Host:
 457
 458 =========
 459 s4u::Host
 460 =========
 461
 462 .. doxygenclass:: simgrid::s4u::Host
 463    :members:
 464    :protected-members:
 465    :undoc-members:
 466
 467 .. _API_s4u_Io:
 468
 469 =======
 470 s4u::Io
 471 =======
 472
 473 .. doxygentypedef:: IoPtr
 474
 475 .. doxygenclass:: simgrid::s4u::Io
 476    :members:
 477    :protected-members:
 478    :undoc-members:
 479
 480 .. _API_s4u_Link:
 481
 482 =========
 483 s4u::Link
 484 =========
 485
 486 .. doxygenclass:: simgrid::s4u::Link
 487    :members:
 488    :protected-members:
 489    :undoc-members:
 490
 491 .. _API_s4u_Mailbox:
 492
 493 ============
 494 s4u::Mailbox
 495 ============
 496
 497 Please also refer to the :ref:`full doc on s4u::Mailbox <s4u_mailbox>`.
 498
 499 .. doxygentypedef:: MailboxPtr
 500
 501 .. doxygenclass:: simgrid::s4u::Mailbox
 502    :members:
 503    :protected-members:
 504    :undoc-members:
 505
 506 .. _API_s4u_Mutex:
 507
 508 ==========
 509 s4u::Mutex
 510 ==========
 511
 512 .. doxygentypedef:: MutexPtr
 513
 514 .. doxygenclass:: simgrid::s4u::Mutex
 515    :members:
 516    :protected-members:
 517    :undoc-members:
 518
 519 .. _API_s4u_NetZone:
 520
 521 ============
 522 s4u::NetZone
 523 ============
 524
 525 .. doxygenclass:: simgrid::s4u::NetZone
 526    :members:
 527    :protected-members:
 528    :undoc-members:
 529
 530 .. _API_s4u_Semaphore:
 531
 532 ==============
 533 s4u::Semaphore
 534 ==============
 535
 536 .. doxygentypedef:: SemaphorePtr
 537
 538 .. doxygenclass:: simgrid::s4u::Semaphore
 539    :members:
 540    :protected-members:
 541    :undoc-members:
 542
 543 .. _API_s4u_Storage:
 544
 545 ============
 546 s4u::Storage
 547 ============
 548
 549 .. doxygenclass:: simgrid::s4u::Storage
 550    :members:
 551    :protected-members:
 552    :undoc-members:
 553
 554 .. _API_s4u_VirtualMachine:
 555
 556 ===================
 557 s4u::VirtualMachine
 558 ===================
 559
 560 .. doxygenclass:: simgrid::s4u::VirtualMachine
 561    :members:
 562    :protected-members:
 563    :undoc-members:
 564