Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
46cc216d9c5bf7472f201e8fc04fe3c26ce161cd
[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 Currently (v3.21), 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