Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
convert cloud-migration
[simgrid.git] / examples / README.rst
1 .. S4U (Simgrid for you) is the modern interface of SimGrid, which new project should use.
2 ..
3 .. This file follows the ReStructured syntax to be included in the
4 .. documentation, but it should remain readable directly.
5
6
7 Examples
8 ********
9
10 SimGrid comes with an extensive set of examples, documented on this
11 page. Most of them only demonstrate one single feature, with some
12 larger examplars listed below. 
13
14 The C++ examples can be found under examples/s4u while python examples
15 are in examples/python. Each such directory contains the source code (also listed
16 from this page), and the so-called tesh file containing how to call
17 the binary obtained by compiling this example and also the expected
18 output. Tesh files are used to turn each of our examples into an
19 integration test. Some examples also contain other files, on need.
20
21 A good way to bootstrap your own project is to copy and combine some
22 of the provided examples to constitute the skeleton of what you plan
23 to simulate.
24
25 .. _s4u_ex_actors:
26
27 ===========================
28 Actors: the Active Entities
29 ===========================
30
31 Starting and Stoping Actors
32 ---------------------------
33
34   - **Creating actors:**
35     Most actors are started from the deployment XML file, because this
36     is a :ref:`better scientific habbit <howto_science>`, but you can
37     also create them directly from your code.
38
39     .. tabs::
40     
41        .. example-tab:: examples/s4u/actor-create/s4u-actor-create.cpp
42        
43           You create actors either:
44              
45           - Directly with :cpp:func:`simgrid::s4u::Actor::create`
46           - From XML with :cpp:func:`simgrid::s4u::Engine::register_actor` (if your actor is a class)
47             or :cpp:func:`simgrid::s4u::Engine::register_function` (if your actor is a function)
48             and then :cpp:func:`simgrid::s4u::Engine::load_deployment`
49              
50        .. example-tab:: examples/python/actor-create/actor-create.py
51        
52           You create actors either:
53             
54           - Directly with :py:func:`simgrid.Actor.create()`
55           - From XML with :py:func:`simgrid.Engine.register_actor()` and then :py:func:`simgrid.Engine.load_deployment()`
56              
57        .. example-tab:: examples/c/actor-create/actor-create.c
58        
59           You create actors either:
60             
61           - Directly with :cpp:func:`sg_actor_create()` followed by :cpp:func:`sg_actor_start`.
62           - From XML with :cpp:func:`simgrid_register_function` and then :cpp:func:`simgrid_load_deployment`.
63              
64        .. example-tab:: examples/python/actor-create/actor-create_d.xml
65        
66           The following file is used in both C++ and Python.
67
68   - **React to the end of actors:** You can attach callbacks to the end of
69     actors. There is several ways of doing so, depending on whether you want to
70     attach your callback to a given actor and on how you define the end of a
71     given actor. User code probably want to react to the termination of an actor
72     while some plugins want to react to the destruction (memory collection) of
73     actors.
74
75     .. tabs::
76     
77        .. example-tab:: examples/s4u/actor-exiting/s4u-actor-exiting.cpp
78
79           This example shows how to attach a callback to:
80
81           - the end of a specific actor: :cpp:func:`simgrid::s4u::this_actor::on_exit()`
82           - the end of any actor: :cpp:member:`simgrid::s4u::Actor::on_termination()`
83           - the destruction of any actor: :cpp:member:`simgrid::s4u::Actor::on_destruction()`
84
85        .. example-tab:: examples/c/actor-exiting/actor-exiting.c
86
87           This example shows how to attach a callback to the end of a specific actor with 
88           :cpp:func:`sg_actor_on_exit()`.
89
90   - **Kill actors:**
91     Actors can forcefully stop other actors.
92
93     .. tabs::
94
95        .. example-tab:: examples/s4u/actor-kill/s4u-actor-kill.cpp
96
97           See also :cpp:func:`void simgrid::s4u::Actor::kill(void)`, :cpp:func:`void simgrid::s4u::Actor::kill_all()`,
98           :cpp:func:`simgrid::s4u::this_actor::exit`, :cpp:func:`simgrid::s4u::this_actor::on_exit`.
99
100        .. example-tab:: examples/python/actor-kill/actor-kill.py
101
102           See also :py:func:`simgrid.Actor.kill`, :py:func:`simgrid.Actor.kill_all`, :py:func:`simgrid.this_actor.exit`,
103           :py:func:`simgrid.this_actor.on_exit`.
104
105        .. example-tab:: examples/c/actor-kill/actor-kill.c
106
107           See also :cpp:func:`sg_actor_kill`, :cpp:func:`sg_actor_kill_all`, :cpp:func:`sg_actor_exit`, :cpp:func:`sg_actor_on_exit`.
108
109   - **Controling the actor life cycle from the XML:**
110     You can specify a start time and a kill time in the deployment file.
111
112     .. tabs::
113
114        .. example-tab:: examples/s4u/actor-lifetime/s4u-actor-lifetime.cpp
115
116           This file is not really interesting: the important matter is in the XML file.
117
118        .. example-tab:: examples/s4u/actor-lifetime/s4u-actor-lifetime_d.xml
119
120           This demonstrates the ``start_time`` and ``kill_time`` attribute of the :ref:`pf_tag_actor` tag.
121
122   - **Daemonize actors:**
123     Some actors may be intended to simulate daemons that run in background. This example show how to transform a regular
124     actor into a daemon that will be automatically killed once the simulation is over.
125     
126     .. tabs::
127
128        .. example-tab:: examples/s4u/actor-daemon/s4u-actor-daemon.cpp
129
130           See also :cpp:func:`simgrid::s4u::Actor::daemonize()` and :cpp:func:`simgrid::s4u::Actor::is_daemon()`.
131
132        .. example-tab:: examples/python/actor-daemon/actor-daemon.py
133
134           See also :py:func:`simgrid.Actor.daemonize()` and :py:func:`simgrid.Actor.is_daemon()`.
135
136        .. example-tab:: examples/c/actor-daemon/actor-daemon.c
137
138           See also :cpp:func:`sg_actor_daemonize` and :cpp:func:`sg_actor_is_daemon`.
139
140 Inter-Actors Interactions
141 -------------------------
142
143 See also the examples on :ref:`inter-actors communications
144 <s4u_ex_communication>` and the ones on :ref:`classical
145 synchronization objects <s4u_ex_IPC>`.
146
147   - **Suspend and Resume actors:**    
148     Actors can be suspended and resumed during their executions.
149
150     .. tabs::
151
152        .. example-tab:: examples/s4u/actor-suspend/s4u-actor-suspend.cpp
153
154           See also :cpp:func:`simgrid::s4u::this_actor::suspend()`,
155           :cpp:func:`simgrid::s4u::Actor::suspend()`, :cpp:func:`simgrid::s4u::Actor::resume()`, and
156           :cpp:func:`simgrid::s4u::Actor::is_suspended()`.
157
158        .. example-tab:: examples/python/actor-suspend/actor-suspend.py
159
160           See also :py:func:`simgrid.this_actor.suspend()`,
161           :py:func:`simgrid.Actor.suspend()`, :py:func:`simgrid.Actor.resume()`, and
162           :py:func:`simgrid.Actor.is_suspended()`.
163
164        .. example-tab:: examples/c/actor-suspend/actor-suspend.c
165
166           See also :cpp:func:`sg_actor_suspend()`, :cpp:func:`sg_actor_resume()`, and 
167           :cpp:func:`sg_actor_is_suspended()`.
168
169   - **Migrating Actors:**
170     Actors can move or be moved from a host to another very easily. It amount to setting them on a new host.
171
172     .. tabs::
173
174        .. example-tab:: examples/s4u/actor-migrate/s4u-actor-migrate.cpp
175
176           See also :cpp:func:`simgrid::s4u::this_actor::set_host()` and :cpp:func:`simgrid::s4u::Actor::set_host()`.
177
178        .. example-tab:: examples/python/actor-migrate/actor-migrate.py
179
180           See also :py:func:`simgrid.this_actor.set_host()` and :py:func:`simgrid.Actor.set_host()`.
181
182        .. example-tab:: examples/c/actor-migrate/actor-migrate.c
183
184           See also :cpp:func:`sg_actor_set_host()`.
185
186   - **Waiting for the termination of an actor:** (joining on it)
187     You can block the current actor until the end of another actor.
188
189     .. tabs::
190
191        .. example-tab:: examples/s4u/actor-join/s4u-actor-join.cpp
192
193           See also :cpp:func:`simgrid::s4u::Actor::join()`.
194
195        .. example-tab:: examples/python/actor-join/actor-join.py
196
197           See also :py:func:`simgrid.Actor.join()`.
198
199        .. example-tab:: examples/c/actor-join/actor-join.c
200
201           See also :cpp:func:`sg_actor_join`.
202
203   - **Yielding to other actors**.
204     The ```yield()``` function interrupts the execution of the current
205     actor, leaving a chance to the other actors that are ready to run
206     at this timestamp.
207
208     .. tabs::
209
210        .. example-tab:: examples/s4u/actor-yield/s4u-actor-yield.cpp
211
212           See also :cpp:func:`simgrid::s4u::this_actor::yield()`.
213
214        .. example-tab:: examples/python/actor-yield/actor-yield.py
215
216           See also :py:func:`simgrid.this_actor.yield_()`.
217
218        .. example-tab:: examples/c/actor-yield/actor-yield.c
219
220           See also :cpp:func:`sg_actor_yield()`.
221
222 Traces Replay as a Workload
223 ---------------------------
224
225 This section details how to run trace-driven simulations. It is very
226 handy when you want to test an algorithm or protocol that only react
227 to external events. For example, many P2P protocols react to user
228 requests, but do nothing if there is no such event.
229
230 In such situations, you should write your protocol in C++, and separate
231 the workload that you want to play onto your protocol in a separate
232 text file. Declare a function handling each type of the events in your
233 trace, register them using :cpp:func:`xbt_replay_action_register()` in
234 your main, and then run the simulation.
235
236 Then, you can either have one trace file containing all your events,
237 or a file per simulated process: the former may be easier to work
238 with, but the second is more efficient on very large traces. Check
239 also the tesh files in the example directories for details.
240
241   - **Communication replay:**
242     Presents a set of event handlers reproducing classical communication
243     primitives (asynchronous send/receive at the moment).
244
245     .. tabs::
246
247        .. example-tab:: examples/s4u/replay-comm/s4u-replay-comm.cpp
248
249   - **I/O replay:**
250     Presents a set of event handlers reproducing classical I/O
251     primitives (open, read, close).
252
253     .. tabs::
254
255        .. example-tab:: examples/s4u/replay-io/s4u-replay-io.cpp
256
257 ==========================
258 Activities: what Actors do
259 ==========================
260
261 .. _s4u_ex_communication:
262
263 Communications on the Network
264 -----------------------------
265
266  - **Basic asynchronous communications:**
267    Illustrates how to have non-blocking communications, that are
268    communications running in the background leaving the process free
269    to do something else during their completion. 
270
271    .. tabs::
272
273       .. example-tab:: examples/s4u/async-wait/s4u-async-wait.cpp
274
275          See also :cpp:func:`simgrid::s4u::Mailbox::put_async()` and :cpp:func:`simgrid::s4u::Comm::wait()`.
276
277       .. example-tab:: examples/python/async-wait/async-wait.py
278
279          See also :py:func:`simgrid.Mailbox.put_async()` and :py:func:`simgrid.Comm.wait()`.
280
281  - **Waiting for all communications in a set:**
282    The ``wait_all()`` function is useful when you want to block until
283    all activities in a given set have completed. 
284    
285    .. tabs::
286
287       .. example-tab:: examples/s4u/async-waitall/s4u-async-waitall.cpp
288
289          See also :cpp:func:`simgrid::s4u::Comm::wait_all()`.
290
291       .. example-tab:: examples/c/async-waitall/async-waitall.c
292
293          See also :cpp:func:`sg_comm_wait_all()`.
294
295       .. example-tab:: examples/python/async-waitall/async-waitall.py
296
297          See also :py:func:`simgrid.Comm.wait_all()`.
298
299  - **Waiting for the first completed communication in a set:**
300    The ``wait_any()`` function is useful
301    when you want to block until one activity of the set completes, no
302    matter which terminates first.
303    
304    .. tabs::
305
306       .. example-tab:: examples/s4u/async-waitany/s4u-async-waitany.cpp
307
308          See also :cpp:func:`simgrid::s4u::Comm::wait_any()`.
309
310       .. example-tab:: examples/python/async-waitany/async-waitany.py
311
312          See also :py:func:`simgrid.Comm.wait_any()`.
313          
314       .. example-tab:: examples/c/async-waitany/async-waitany.c
315
316          See also :cpp:func:`sg_comm_wait_any`.
317      
318 .. _s4u_ex_execution:
319
320 Executions on the CPU
321 ---------------------
322
323   - **Basic execution:**
324     The computations done in your program are not reported to the
325     simulated world, unless you explicitly request the simulator to pause
326     the actor until a given amount of flops gets computed on its simulated
327     host. Some executions can be given an higher priority so that they
328     get more resources.
329
330     .. tabs::
331
332        .. example-tab:: examples/s4u/exec-basic/s4u-exec-basic.cpp
333
334           See also :cpp:func:`void simgrid::s4u::this_actor::execute(double)`
335           and :cpp:func:`void simgrid::s4u::this_actor::execute(double, double)`.
336
337        .. example-tab:: examples/python/exec-basic/exec-basic.py
338
339           See also :py:func:`simgrid.this_actor.execute()`.
340
341   - **Asynchronous execution:**
342     You can start asynchronous executions, just like you would fire
343     background threads.
344
345     .. tabs::
346
347        .. example-tab:: examples/s4u/exec-async/s4u-exec-async.cpp
348
349           See also :cpp:func:`simgrid::s4u::this_actor::exec_init()`,
350           :cpp:func:`simgrid::s4u::Activity::start()`,
351           :cpp:func:`simgrid::s4u::Activity::wait()`,
352           :cpp:func:`simgrid::s4u::Activity::get_remaining()`,
353           :cpp:func:`simgrid::s4u::Exec::get_remaining_ratio()`,
354           :cpp:func:`simgrid::s4u::this_actor::exec_async()` and
355           :cpp:func:`simgrid::s4u::Activity::cancel()`.
356
357        .. example-tab:: examples/python/exec-async/exec-async.py
358     
359           See also :py:func:`simgrid.this_actor::exec_init()`,
360           :py:func:`simgrid.Activity::start()`,
361           :py:func:`simgrid.Activity.wait()`,
362           :py:func:`simgrid.Activity.get_remaining()`,
363           :py:func:`simgrid.Exec.get_remaining_ratio()`,
364           :py:func:`simgrid.this_actor.exec_async()` and
365           :py:func:`simgrid.Activity.cancel()`.
366
367   - **Remote execution:**
368     You can start executions on remote hosts, or even change the host
369     on which they occur during their execution.
370
371     .. tabs::
372
373        .. example-tab:: examples/s4u/exec-remote/s4u-exec-remote.cpp
374
375           See also :cpp:func:`simgrid::s4u::Exec::set_host()`.
376
377        .. example-tab:: examples/python/exec-remote/exec-remote.py
378
379           See also :py:func:`simgrid.Exec.set_host()`.
380
381   - **Parallel executions:**
382     These objects are convenient abstractions of parallel
383     computational kernels that span over several machines, such as a
384     PDGEM and the other ScaLAPACK routines. Note that this only works
385     with the "ptask_L07" host model (``--cfg=host/model:ptask_L07``).
386
387     .. tabs::
388
389        .. example-tab:: examples/s4u/exec-ptask/s4u-exec-ptask.cpp
390     
391           See also :cpp:func:`simgrid::s4u::this_actor::parallel_execute()`.
392
393   - **Using Pstates on a host:**
394     This example shows how define a set of pstates in the XML. The current pstate
395     of an host can then be accessed and changed from the program.
396
397     .. tabs::
398
399        .. example-tab:: examples/s4u/exec-dvfs/s4u-exec-dvfs.cpp
400
401           See also :cpp:func:`simgrid::s4u::Host::get_pstate_speed` and :cpp:func:`simgrid::s4u::Host::set_pstate`.
402
403        .. example-tab:: examples/c/exec-dvfs/exec-dvfs.c
404
405           See also :cpp:func:`sg_host_get_pstate_speed` and :cpp:func:`sg_host_set_pstate`.
406
407        .. example-tab:: examples/python/exec-dvfs/exec-dvfs.py
408
409           See also :py:func:`Host.get_pstate_speed` and :py:func:`Host.set_pstate`.
410
411        .. example-tab:: examples/platforms/energy_platform.xml
412
413 .. _s4u_ex_disk_io:
414
415 I/O on Disks and Files
416 ----------------------
417
418 SimGrid provides two levels of abstraction to interact with the
419 simulated disks. At the simplest level, you simply create read and
420 write actions on the disk resources.
421
422   - **Access to raw disk devices:**
423     This example illustrates how to simply read and write data on a
424     simulated disk resource.
425
426     .. tabs::
427
428        .. example-tab:: examples/s4u/io-disk-raw/s4u-io-disk-raw.cpp
429
430        .. example-tab:: examples/c/io-disk-raw/io-disk-raw.c
431
432        .. example-tab:: examples/platforms/hosts_with_disks.xml
433
434           This shows how to declare disks in XML.
435
436 The FileSystem plugin provides a more detailed view, with the
437 classical operations over files: open, move, unlink, and of course
438 read and write. The file and disk sizes are also dealt with and can
439 result in short reads and short write, as in reality.
440
441   - **File Management:**
442     This example illustrates the use of operations on files
443     (read, write, seek, tell, unlink, etc).
444
445     .. tabs::
446
447        .. example-tab:: examples/s4u/io-file-system/s4u-io-file-system.cpp
448
449   - **Remote I/O:**
450     I/O operations on files can also be done in a remote fashion, 
451     i.e. when the accessed disk is not mounted on the caller's host.
452
453     .. tabs::
454
455        .. example-tab:: examples/s4u/io-file-remote/s4u-io-file-remote.cpp
456
457        .. example-tab:: examples/c/io-file-remote/io-file-remote.c
458
459 .. _s4u_ex_IPC:
460
461 Classical synchronization objects
462 ---------------------------------
463
464  - **Barrier:**
465    Shows how to use :cpp:type:`simgrid::s4u::Barrier` synchronization objects.
466
467    .. tabs::
468
469       .. example-tab:: examples/s4u/synchro-barrier/s4u-synchro-barrier.cpp
470
471  - **Condition variable:**
472    Shows how to use :cpp:type:`simgrid::s4u::ConditionVariable` synchronization objects.
473
474    .. tabs::
475
476       .. example-tab:: examples/s4u/synchro-condition-variable/s4u-synchro-condition-variable.cpp
477
478  - **Mutex:**
479    Shows how to use :cpp:type:`simgrid::s4u::Mutex` synchronization objects.
480
481    .. tabs::
482
483       .. example-tab:: examples/s4u/synchro-mutex/s4u-synchro-mutex.cpp
484
485  - **Semaphore:**
486    Shows how to use :cpp:type:`simgrid::s4u::Semaphore` synchronization objects.
487
488    .. tabs::
489
490       .. example-tab:: examples/s4u/synchro-semaphore/s4u-synchro-semaphore.cpp
491
492 =============================
493 Interacting with the Platform
494 =============================
495
496  - **User-defined properties:**
497    You can attach arbitrary information to most platform elements from
498    the XML file, and then interact with these values from your
499    program. Note that the changes are not written permanently on disk,
500    in the XML file nor anywhere else. They only last until the end of
501    your simulation.
502
503    .. tabs::
504
505       .. example-tab:: examples/s4u/platform-properties/s4u-platform-properties.cpp
506
507          - :cpp:func:`simgrid::s4u::Actor::get_property()` and :cpp:func:`simgrid::s4u::Actor::set_property()`
508          - :cpp:func:`simgrid::s4u::Host::get_property()` and :cpp:func:`simgrid::s4u::Host::set_property()`
509          - :cpp:func:`simgrid::s4u::Link::get_property()` and :cpp:func:`simgrid::s4u::Link::set_property()`
510          - :cpp:func:`simgrid::s4u::NetZone::get_property()` and :cpp:func:`simgrid::s4u::NetZone::set_property()`
511
512       .. group-tab:: XML
513
514          **Deployment file:**
515
516          .. showfile:: examples/s4u/platform-properties/s4u-platform-properties_d.xml
517             :language: xml
518
519          |br|
520          **Platform file:**
521
522          .. showfile:: examples/platforms/prop.xml
523             :language: xml
524
525  - **Retrieving the netzones matching a given criteria:**
526    Shows how to filter the cluster netzones.
527
528    .. tabs::
529
530       .. example-tab:: examples/s4u/routing-get-clusters/s4u-routing-get-clusters.cpp
531
532  - **Retrieving the list of hosts matching a given criteria:**
533    Shows how to filter the actors that match a given criteria.
534
535    .. tabs::
536
537       .. example-tab:: examples/s4u/engine-filtering/s4u-engine-filtering.cpp
538
539  - **Specifying state profiles:** shows how to specify when the
540    resources must be turned off and on again, and how to react to such
541    failures in your code. See also :ref:`howto_churn`.
542
543    .. tabs::
544
545       .. example-tab:: examples/s4u/platform-failures/s4u-platform-failures.cpp
546
547       .. group-tab:: XML
548
549          .. showfile:: examples/platforms/small_platform_failures.xml
550             :language: xml
551
552          .. showfile:: examples/platforms/profiles/jupiter_state.profile
553
554          .. showfile:: examples/platforms/profiles/bourassa_state.profile
555
556          .. showfile:: examples/platforms/profiles/fafard_state.profile
557
558  - **Specifying speed profiles:** shows how to specify an external
559    load to resources, variating their peak speed over time.
560
561    .. tabs::
562
563       .. example-tab:: examples/s4u/platform-profile/s4u-platform-profile.cpp
564
565       .. group-tab:: XML  
566
567          .. showfile:: examples/platforms/small_platform_profile.xml
568             :language: xml
569
570          .. showfile:: examples/platforms/profiles/jupiter_speed.profile
571
572          .. showfile:: examples/platforms/profiles/link1_bandwidth.profile
573
574          .. showfile:: examples/platforms/profiles/link1_latency.profile
575
576 =================
577 Energy Simulation
578 =================
579
580   - **Describing the energy profiles in the platform:**
581     This platform file contains the energy profile of each links and
582     hosts, which is necessary to get energy consumption predictions.
583     As usual, you should not trust our example, and you should strive
584     to double-check that your instantiation matches your target platform.
585
586     .. tabs::
587
588        .. example-tab:: examples/platforms/energy_platform.xml
589
590   - **Consumption due to the CPU:** 
591     This example shows how to retrieve the amount of energy consumed
592     by the CPU during computations, and the impact of the pstate.
593
594     .. tabs::
595
596        .. example-tab:: examples/s4u/energy-exec/s4u-energy-exec.cpp
597
598        .. example-tab:: examples/c/energy-exec/energy-exec.c
599
600   - **Consumption due to the network:**
601     This example shows how to retrieve and display the energy consumed
602     by the network during communications.
603
604     .. tabs::
605
606        .. example-tab:: examples/s4u/energy-link/s4u-energy-link.cpp
607
608   - **Modeling the shutdown and boot of hosts:**
609     Simple example of model of model for the energy consumption during
610     the host boot and shutdown periods.
611
612     .. tabs::
613
614        .. example-tab:: examples/s4u/energy-boot/platform_boot.xml
615
616        .. example-tab:: examples/s4u/energy-boot/s4u-energy-boot.cpp
617
618 =======================
619 Tracing and Visualizing
620 =======================
621
622 Tracing can be activated by various configuration options which
623 are illustrated in these example. See also the 
624 :ref:`full list of options related to tracing <tracing_tracing_options>`.
625
626 It is interesting to run the process-create example with the following
627 options to see the task executions:
628
629   - **Platform Tracing:**
630     This program is a toy example just loading the platform, so that
631     you can play with the platform visualization. Recommanded options:
632     ``--cfg=tracing:yes --cfg=tracing/categorized:yes``
633
634     .. tabs::
635
636        .. example-tab:: examples/s4u/trace-platform/s4u-trace-platform.cpp
637
638 ========================
639 Larger SimGrid Examplars
640 ========================
641
642 This section contains application examples that are somewhat larger
643 than the previous examples.
644
645   - **Ping Pong:**
646     This simple example just sends one message back and forth.
647     The tesh file laying in the directory show how to start the simulator binary, highlighting how to pass options to 
648     the simulators (as detailed in Section :ref:`options`).
649
650     .. tabs::
651
652        .. example-tab:: examples/s4u/app-pingpong/s4u-app-pingpong.cpp
653
654        .. example-tab:: examples/c/app-pingpong/app-pingpong.c
655
656   - **Token ring:**
657     Shows how to implement a classical communication pattern, where a
658     token is exchanged along a ring to reach every participant.
659
660     .. tabs::
661
662        .. example-tab:: examples/s4u/app-token-ring/s4u-app-token-ring.cpp
663
664        .. example-tab:: examples/c/app-token-ring/app-token-ring.c
665
666   - **Master Workers:**
667     Another good old example, where one Master process has a bunch of task to dispatch to a set of several Worker 
668     processes.
669
670     .. tabs::
671
672        .. group-tab:: C++
673
674           This example comes in two equivalent variants, one where the actors
675           are specified as simple functions (which is easier to understand for
676           newcomers) and one where the actors are specified as classes (which is
677           more powerful for the users wanting to build their own projects upon
678           the example).
679
680           .. showfile:: examples/s4u/app-masterworkers/s4u-app-masterworkers-class.cpp
681              :language: cpp
682
683           .. showfile:: examples/s4u/app-masterworkers/s4u-app-masterworkers-fun.cpp
684              :language: cpp
685     
686 Data diffusion
687 --------------
688
689   - **Bit Torrent:** 
690     Classical protocol for Peer-to-Peer data diffusion.
691
692     .. tabs::
693
694        .. group-tab:: C++
695
696           .. showfile:: examples/s4u/app-bittorrent/s4u-bittorrent.cpp
697              :language: cpp
698
699           .. showfile:: examples/s4u/app-bittorrent/s4u-peer.cpp
700              :language: cpp
701
702           .. showfile:: examples/s4u/app-bittorrent/s4u-tracker.cpp
703              :language: cpp
704
705   - **Chained Send:** 
706     Data broadcast over a ring of processes.
707
708     .. tabs::
709
710        .. example-tab:: examples/s4u/app-chainsend/s4u-app-chainsend.cpp
711
712        .. group-tab:: C
713
714           .. showfile:: examples/c/app-chainsend/chainsend.c
715              :language: c
716
717           .. showfile:: examples/c/app-chainsend/broadcaster.c
718              :language: c
719
720           .. showfile:: examples/c/app-chainsend/peer.c
721              :language: c
722
723 Distributed Hash Tables (DHT)
724 -----------------------------
725
726   - **Chord Protocol** 
727     One of the most famous DHT protocol.
728
729     .. tabs::
730
731        .. group-tab:: C++
732
733           .. showfile:: examples/s4u/dht-chord/s4u-dht-chord.cpp
734              :language: cpp
735
736           .. showfile:: examples/s4u/dht-chord/s4u-dht-chord-node.cpp
737              :language: cpp
738
739   - **Kademlia**
740     Another well-known DHT protocol.
741
742     .. tabs::
743
744        .. group-tab:: C++
745
746           .. showfile:: examples/s4u/dht-kademlia/s4u-dht-kademlia.cpp
747              :language: cpp
748
749           .. showfile:: examples/s4u/dht-kademlia/routing_table.cpp
750              :language: cpp
751
752           .. showfile:: examples/s4u/dht-kademlia/answer.cpp
753              :language: cpp
754
755           .. showfile:: examples/s4u/dht-kademlia/node.cpp
756              :language: cpp
757
758 .. _s4u_ex_clouds:
759
760 Simulating Clouds
761 -----------------
762
763   - **Cloud basics**
764     This example starts some computations both on PMs and VMs, and
765     migrates some VMs around.
766
767     .. tabs::
768
769        .. example-tab:: examples/s4u/cloud-simple/s4u-cloud-simple.cpp
770
771        .. example-tab:: examples/c/cloud-simple/cloud-simple.c
772
773   - **Migrating VMs**
774     This example shows how to migrate VMs between PMs.
775
776     .. tabs::
777
778        .. example-tab:: examples/s4u/cloud-migration/s4u-cloud-migration.cpp
779
780        .. example-tab:: examples/c/cloud-migration/cloud-migration.c
781
782 =======================
783 Model-Checking Examples
784 =======================
785
786 The model-checker can be used to exhaustively search for issues in the
787 tested application. It must be activated at compile time, but this
788 mode is rather experimental in SimGrid (as of v3.22). You should not
789 enable it unless you really want to formally verify your applications:
790 SimGrid is slower and maybe less robust when MC is enabled.
791
792   - **Failing assert**
793     In this example, two actors send some data to a central server,
794     which asserts that the messages are always received in the same order.
795     This is obviously wrong, and the model-checker correctly finds a
796     counter-example to that assertion.
797
798     .. tabs::
799
800        .. example-tab:: examples/s4u/mc-failing-assert/s4u-mc-failing-assert.cpp
801
802 .. |br| raw:: html
803
804    <br />
805
806 .. |cpp| image:: /img/lang_cpp.png
807    :align: middle
808    :width: 12
809
810 .. |py| image:: /img/lang_python.png
811    :align: middle
812    :width: 12