Logo AND Algorithmique Numérique Distribuée

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