Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
Move the S4U examples to another chapter
[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 .. _s4u_examples:
7
8 S4U Examples
9 ############
10
11 SimGrid comes with an extensive set of examples, documented on this
12 page. Most of them only demonstrate one single feature, with some
13 larger exemplars listed below.
14
15 The C++ examples can be found under examples/cpp while python examples
16 are in examples/python. Each such directory contains the source code (also listed
17 from this page), and the so-called tesh file containing how to call
18 the binary obtained by compiling this example and also the expected
19 output. Tesh files are used to turn each of our examples into an
20 integration test. Some examples also contain other files, on need.
21
22 A good way to bootstrap your own project is to copy and combine some
23 of the provided examples to constitute the skeleton of what you plan
24 to simulate.
25
26 .. _s4u_ex_actors:
27
28 ***************************
29 Actors: the Active Entities
30 ***************************
31
32 Starting and Stopping Actors
33 ============================
34
35 .. _s4u_ex_actors_create:
36
37 Creating actors
38 ---------------
39
40 Most actors are started from the deployment XML file because this
41 is a :ref:`better scientific habit <howto_science>`, but you can
42 also create them directly from your code.
43
44 .. tabs::
45
46    .. example-tab:: examples/cpp/actor-create/s4u-actor-create.cpp
47
48       You create actors either:
49
50       - Directly with :cpp:func:`simgrid::s4u::Actor::create`
51       - From XML with :cpp:func:`simgrid::s4u::Engine::register_actor` (if your actor is a class)
52         or :cpp:func:`simgrid::s4u::Engine::register_function` (if your actor is a function)
53         and then :cpp:func:`simgrid::s4u::Engine::load_deployment`
54
55    .. example-tab:: examples/python/actor-create/actor-create.py
56
57       You create actors either:
58
59       - Directly with :py:func:`simgrid.Actor.create()`
60       - From XML with :py:func:`simgrid.Engine.register_actor()` and then :py:func:`simgrid.Engine.load_deployment()`
61
62    .. example-tab:: examples/c/actor-create/actor-create.c
63
64       You create actors either:
65
66       - Directly with :cpp:func:`sg_actor_create` followed by :cpp:func:`sg_actor_start`.
67       - From XML with :cpp:func:`simgrid_register_function` and then :cpp:func:`simgrid_load_deployment`.
68
69    .. example-tab:: examples/python/actor-create/actor-create_d.xml
70
71       The following file is used in both C++ and Python.
72
73 Reacting to actors' end
74 -----------------------
75
76 You can attach callbacks to the end of actors. There are several ways of doing so, depending on whether you want to
77 attach your callback to a given actor and on how you define the end of a
78 given actor. User code probably wants to react to the termination of an actor
79 while some plugins want to react to the destruction (memory collection) of
80 actors.
81
82 .. tabs::
83
84    .. example-tab:: examples/cpp/actor-exiting/s4u-actor-exiting.cpp
85
86       This example shows how to attach a callback to:
87
88       - the end of a specific actor: :cpp:func:`simgrid::s4u::Actor::on_exit()`
89       - the end of any actor: :cpp:func:`simgrid::s4u::Actor::on_termination_cb`
90       - the destruction of any actor: :cpp:func:`simgrid::s4u::Actor::on_destruction_cb`
91
92    .. example-tab:: examples/c/actor-exiting/actor-exiting.c
93
94       This example shows how to attach a callback to the end of a specific actor with
95       :cpp:func:`sg_actor_on_exit()`.
96
97 Killing actors
98 --------------
99
100 Actors can forcefully stop other actors.
101
102 .. tabs::
103
104    .. example-tab:: examples/cpp/actor-kill/s4u-actor-kill.cpp
105
106       See also :cpp:func:`void simgrid::s4u::Actor::kill(void)`, :cpp:func:`void simgrid::s4u::Actor::kill_all()`,
107       :cpp:func:`simgrid::s4u::this_actor::exit`, :cpp:func:`simgrid::s4u::Actor::on_exit`.
108
109    .. example-tab:: examples/python/actor-kill/actor-kill.py
110
111       See also :py:func:`simgrid.Actor.kill()`, :py:func:`simgrid.Actor.kill_all()`, :py:func:`simgrid.this_actor.exit()`,
112       :py:func:`simgrid.this_actor.on_exit`.
113
114    .. example-tab:: examples/c/actor-kill/actor-kill.c
115
116       See also :cpp:func:`sg_actor_kill`, :cpp:func:`sg_actor_kill_all`, :cpp:func:`sg_actor_exit`, :cpp:func:`sg_actor_on_exit`.
117
118 Actors' life cycle from XML_reference
119 -------------------------------------
120
121 You can specify a start time and a kill time in the deployment file.
122
123 .. tabs::
124
125    .. example-tab:: examples/cpp/actor-lifetime/s4u-actor-lifetime.cpp
126
127       This file is not really interesting: the important matter is in the XML file.
128
129    .. example-tab:: examples/cpp/actor-lifetime/s4u-actor-lifetime_d.xml
130
131       This demonstrates the ``start_time`` and ``kill_time`` attribute of the :ref:`pf_tag_actor` tag.
132
133    .. example-tab:: examples/python/actor-lifetime/actor-lifetime.py
134
135       This file is not really interesting: the important matter is in the XML file.
136
137    .. example-tab:: examples/c/actor-lifetime/actor-lifetime.c
138
139       This file is not really interesting: the important matter is in the XML file.
140
141 Daemon actors
142 -------------
143
144 Some actors may be intended to simulate daemons that run in the background.
145 This example shows how to transform a regular
146 actor into a daemon that will be automatically killed once the simulation is over.
147
148 .. tabs::
149
150    .. example-tab:: examples/cpp/actor-daemon/s4u-actor-daemon.cpp
151
152       See also :cpp:func:`simgrid::s4u::Actor::daemonize()` and :cpp:func:`simgrid::s4u::Actor::is_daemon()`.
153
154    .. example-tab:: examples/python/actor-daemon/actor-daemon.py
155
156       See also :py:func:`simgrid.Actor.daemonize()` and :py:func:`simgrid.Actor.is_daemon()`.
157
158    .. example-tab:: examples/c/actor-daemon/actor-daemon.c
159
160       See also :cpp:func:`sg_actor_daemonize` and :cpp:func:`sg_actor_is_daemon`.
161
162 Specifying the stack size
163 -------------------------
164
165 The stack size can be specified by default on the command line,
166 globally by changing the configuration with :cpp:func:`simgrid::s4u::Engine::set_config`,
167 or for a specific actor using :cpp:func:`simgrid::s4u::Actor::set_stacksize` before its start.
168
169 .. tabs::
170
171    .. example-tab:: examples/cpp/actor-stacksize/s4u-actor-stacksize.cpp
172
173    .. example-tab:: examples/c/actor-stacksize/actor-stacksize.c
174
175 Inter-Actors Interactions
176 =========================
177
178 See also the examples on :ref:`inter-actors communications
179 <s4u_ex_communication>` and the ones on :ref:`classical
180 synchronization objects <s4u_ex_IPC>`.
181
182 Suspending/resuming Actors
183 --------------------------
184
185 Actors can be suspended and resumed during their executions.
186
187 .. tabs::
188
189    .. example-tab:: examples/cpp/actor-suspend/s4u-actor-suspend.cpp
190
191       See also :cpp:func:`simgrid::s4u::this_actor::suspend()`,
192       :cpp:func:`simgrid::s4u::Actor::suspend()`, :cpp:func:`simgrid::s4u::Actor::resume()`, and
193       :cpp:func:`simgrid::s4u::Actor::is_suspended()`.
194
195    .. example-tab:: examples/python/actor-suspend/actor-suspend.py
196
197       See also :py:func:`simgrid.this_actor.suspend()`,
198       :py:func:`simgrid.Actor.suspend()`, :py:func:`simgrid.Actor.resume()`, and
199       :py:func:`simgrid.Actor.is_suspended()`.
200
201    .. example-tab:: examples/c/actor-suspend/actor-suspend.c
202
203       See also :cpp:func:`sg_actor_suspend()`, :cpp:func:`sg_actor_resume()`, and
204       :cpp:func:`sg_actor_is_suspended()`.
205
206 Migrating Actors
207 ----------------
208
209 Actors can move or be moved from a host to another very easily. It amounts to setting them on a new host.
210
211 .. tabs::
212
213    .. example-tab:: examples/cpp/actor-migrate/s4u-actor-migrate.cpp
214
215       See also :cpp:func:`simgrid::s4u::this_actor::set_host()` and :cpp:func:`simgrid::s4u::Actor::set_host()`.
216
217    .. example-tab:: examples/python/actor-migrate/actor-migrate.py
218
219       See also :py:attr:`simgrid.Actor.host`.
220
221    .. example-tab:: examples/c/actor-migrate/actor-migrate.c
222
223       See also :cpp:func:`sg_actor_set_host()`.
224
225 Waiting for the termination of an actor (joining on it)
226 -------------------------------------------------------
227
228 You can block the current actor until the end of another actor.
229
230 .. tabs::
231
232    .. example-tab:: examples/cpp/actor-join/s4u-actor-join.cpp
233
234       See also :cpp:func:`simgrid::s4u::Actor::join()`.
235
236    .. example-tab:: examples/python/actor-join/actor-join.py
237
238       See also :py:func:`simgrid.Actor.join()`.
239
240    .. example-tab:: examples/c/actor-join/actor-join.c
241
242       See also :cpp:func:`sg_actor_join`.
243
244 Yielding to other actors
245 ------------------------
246
247 The ```yield()``` function interrupts the execution of the current
248 actor, leaving a chance to the other actors that are ready to run
249 at this timestamp.
250
251 .. tabs::
252
253    .. example-tab:: examples/cpp/actor-yield/s4u-actor-yield.cpp
254
255       See also :cpp:func:`simgrid::s4u::this_actor::yield()`.
256
257    .. example-tab:: examples/python/actor-yield/actor-yield.py
258
259       See also :py:func:`simgrid.this_actor.yield_()`.
260
261    .. example-tab:: examples/c/actor-yield/actor-yield.c
262
263       See also :cpp:func:`sg_actor_yield()`.
264
265 Traces Replay as a Workload
266 ===========================
267
268 This section details how to run trace-driven simulations. It is very
269 handy when you want to test an algorithm or protocol that only reacts
270 to external events. For example, many P2P protocols react to user
271 requests, but do nothing if there is no such event.
272
273 In such situations, you should write your protocol in C++, and separate
274 the workload that you want to play onto your protocol in a separate
275 text file. Declare a function handling each type of the events in your
276 trace, register them using :cpp:func:`xbt_replay_action_register()` in
277 your main, and then run the simulation.
278
279 Then, you can either have one trace file containing all your events,
280 or a file per simulated process: the former may be easier to work
281 with, but the second is more efficient on very large traces. Check
282 also the tesh files in the example directories for details.
283
284 Communication replay
285 --------------------
286
287 Presents a set of event handlers reproducing classical communication primitives (asynchronous send/receive at the moment).
288
289 .. tabs::
290
291    .. example-tab:: examples/cpp/replay-comm/s4u-replay-comm.cpp
292
293 I/O replay
294 ----------
295
296 Presents a set of event handlers reproducing classical I/O primitives (open, read, close).
297
298 .. tabs::
299
300    .. example-tab:: examples/cpp/replay-io/s4u-replay-io.cpp
301
302 **************************
303 Activities: what Actors do
304 **************************
305
306 .. _s4u_ex_communication:
307
308 Communications on the Network
309 =============================
310
311 Basic communications
312 --------------------
313
314 This simple example just sends one message back and forth.
315 The tesh file laying in the directory shows how to start the simulator binary, highlighting how to pass options to
316 the simulators (as detailed in Section :ref:`options`).
317
318 .. tabs::
319
320    .. example-tab:: examples/cpp/comm-pingpong/s4u-comm-pingpong.cpp
321
322    .. example-tab:: examples/python/comm-pingpong/comm-pingpong.py
323
324    .. example-tab:: examples/c/comm-pingpong/comm-pingpong.c
325
326 Basic asynchronous communications
327 ---------------------------------
328
329 Illustrates how to have non-blocking communications, that are communications running in the background leaving the process
330 free to do something else during their completion.
331
332 .. tabs::
333
334    .. example-tab:: examples/cpp/comm-wait/s4u-comm-wait.cpp
335
336       See also :cpp:func:`simgrid::s4u::Mailbox::put_async()` and :cpp:func:`simgrid::s4u::Comm::wait()`.
337
338    .. example-tab:: examples/python/comm-wait/comm-wait.py
339
340       See also :py:func:`simgrid.Mailbox.put_async()` and :py:func:`simgrid.Comm.wait()`.
341
342    .. example-tab:: examples/c/comm-wait/comm-wait.c
343
344       See also :cpp:func:`sg_mailbox_put_async()` and :cpp:func:`sg_comm_wait()`.
345
346 Waiting for communications with timeouts
347 ----------------------------------------
348
349 There is two ways of declaring timeouts in SimGrid. ``waituntil`` let you specify the deadline until when you want to wait, while
350 ``waitfor`` expects the maximal wait duration.
351 This example is very similar to the previous one, simply adding how to declare timeouts when waiting on asynchronous communication.
352
353 .. tabs::
354
355    .. example-tab:: examples/cpp/comm-waituntil/s4u-comm-waituntil.cpp
356
357       See also :cpp:func:`simgrid::s4u::Activity::wait_until()` and :cpp:func:`simgrid::s4u::Comm::wait_for()`.
358
359    .. example-tab:: examples/python/comm-waituntil/comm-waituntil.py
360
361       See also :py:func:`simgrid.Comm.wait_until()`
362
363 .. _s4u_ex_mailbox_ready:
364
365 Checking for incoming communications
366 ------------------------------------
367
368 This example uses ``Mailbox.ready()`` to check for completed communications. When this function returns true, then at least a message
369 is arrived, so you know that ``Mailbox.get()`` will complete imediately. This is thus another way toward asynchronous communications.
370
371 .. tabs::
372
373    .. example-tab:: examples/cpp/comm-ready/s4u-comm-ready.cpp
374
375       See also :cpp:func:`simgrid::s4u::Mailbox::ready()`.
376
377    .. example-tab:: examples/python/comm-ready/comm-ready.py
378
379       See also :py:func:`simgrid.Mailbox.ready()`
380
381
382 Suspending communications
383 -------------------------
384
385 The ``suspend()`` and ``resume()`` functions block the progression of a given communication for a while and then unblock it.
386 ``is_suspended()`` returns whether that activity is currently blocked or not.
387
388 .. tabs::
389
390    .. example-tab:: examples/cpp/comm-suspend/s4u-comm-suspend.cpp
391
392       See also :cpp:func:`simgrid::s4u::Activity::suspend()`
393       :cpp:func:`simgrid::s4u::Activity::resume()` and
394       :cpp:func:`simgrid::s4u::Activity::is_suspended()`.
395
396    .. example-tab:: examples/python/comm-suspend/comm-suspend.py
397
398       See also :py:func:`simgrid.Comm::suspend()` and
399       :py:func:`simgrid.Comm.resume()`.
400
401 Waiting for all communications in a set
402 ---------------------------------------
403
404 The ``wait_all()`` function is useful when you want to block until all activities in a given set have been completed.
405
406 .. tabs::
407
408    .. example-tab:: examples/cpp/comm-waitall/s4u-comm-waitall.cpp
409
410       See also :cpp:func:`simgrid::s4u::Comm::wait_all()`.
411
412    .. example-tab:: examples/python/comm-waitall/comm-waitall.py
413
414       See also :py:func:`simgrid.Comm.wait_all()`.
415
416    .. example-tab:: examples/c/comm-waitall/comm-waitall.c
417
418       See also :cpp:func:`sg_comm_wait_all()`.
419
420 Waiting for the first completed communication in a set
421 ------------------------------------------------------
422
423 The ``wait_any()`` blocks until one activity of the set completes, no matter which terminates first.
424
425 .. tabs::
426
427    .. example-tab:: examples/cpp/comm-waitany/s4u-comm-waitany.cpp
428
429       See also :cpp:func:`simgrid::s4u::Comm::wait_any()`.
430
431    .. example-tab:: examples/python/comm-waitany/comm-waitany.py
432
433       See also :py:func:`simgrid.Comm.wait_any()`.
434
435    .. example-tab:: examples/c/comm-waitany/comm-waitany.c
436
437       See also :cpp:func:`sg_comm_wait_any`.
438
439 Testing whether at least one communication completed
440 ----------------------------------------------------
441
442 The ``test_any()`` returns whether at least one activity of the set has completed, or -1.
443
444 .. tabs::
445
446    .. example-tab:: examples/cpp/comm-testany/s4u-comm-testany.cpp
447
448       See also :cpp:func:`simgrid::s4u::Comm::test_any()`.
449
450    .. example-tab:: examples/python/comm-testany/comm-testany.py
451
452       See also :py:func:`simgrid.Comm.test_any()`.
453
454 .. _s4u_ex_comm_failure:
455
456 Dealing with network failures
457 -----------------------------
458
459 This examples shows how to survive to network exceptions that occurs when a link is turned off, or when the actor with whom
460 you communicate fails because its host is turned off. In this case, any blocking operation such as ``put``, ``get`` or
461 ``wait`` will raise an exception that you can catch and react to. See also :ref:`howto_churn`,
462 :ref:`this example <s4u_ex_platform_state_profile>` on how to attach a state profile to hosts and
463 :ref:`that example <s4u_ex_exec_failure>` on how to react to host failures.
464
465 .. tabs::
466
467    .. example-tab:: examples/cpp/comm-failure/s4u-comm-failure.cpp
468
469    .. example-tab:: examples/python/comm-failure/comm-failure.py
470
471 .. _s4u_ex_comm_host2host:
472
473 Direct host-to-host communication
474 ---------------------------------
475
476 This example demonstrates the direct communication mechanism, that allows to send data from one host to another without
477 relying on the mailbox mechanism.
478
479 .. tabs::
480
481    .. example-tab:: examples/cpp/comm-host2host/s4u-comm-host2host.cpp
482
483       See also :cpp:func:`simgrid::s4u::Comm::sendto_init()` and  :cpp:func:`simgrid::s4u::Comm::sendto_async()`.
484
485    .. example-tab:: examples/python/comm-host2host/comm-host2host.py
486
487       See also :py:func:`simgrid.Comm.sendto_init()` and  :py:func:`simgrid.Comm.sendto_async()`.
488
489 .. _s4u_ex_execution:
490
491 Executions on the CPU
492 =====================
493
494 Basic execution
495 ---------------
496
497 The computations done in your program are not reported to the
498 simulated world unless you explicitly request the simulator to pause
499 the actor until a given amount of flops gets computed on its simulated
500 host. Some executions can be given a higher priority so that they
501 get more resources.
502
503 .. tabs::
504
505    .. example-tab:: examples/cpp/exec-basic/s4u-exec-basic.cpp
506
507       See also :cpp:func:`void simgrid::s4u::this_actor::execute(double)`
508       and :cpp:func:`void simgrid::s4u::this_actor::execute(double, double)`.
509
510    .. example-tab:: examples/python/exec-basic/exec-basic.py
511
512       See also :py:func:`simgrid.this_actor.execute()`.
513
514    .. example-tab:: examples/c/exec-basic/exec-basic.c
515
516       See also :cpp:func:`void sg_actor_execute(double)`
517       and :cpp:func:`void sg_actor_execute_with_priority(double, double)`.
518
519 Asynchronous execution
520 ----------------------
521
522 You can start asynchronous executions, just like you would fire background threads.
523
524 .. tabs::
525
526    .. example-tab:: examples/cpp/exec-async/s4u-exec-async.cpp
527
528       See also :cpp:func:`simgrid::s4u::this_actor::exec_init()`,
529       :cpp:func:`simgrid::s4u::Activity::start()`,
530       :cpp:func:`simgrid::s4u::Activity::wait()`,
531       :cpp:func:`simgrid::s4u::Activity::get_remaining()`,
532       :cpp:func:`simgrid::s4u::Exec::get_remaining_ratio()`,
533       :cpp:func:`simgrid::s4u::this_actor::exec_async()` and
534       :cpp:func:`simgrid::s4u::Activity::cancel()`.
535
536    .. example-tab:: examples/python/exec-async/exec-async.py
537
538       See also :py:func:`simgrid.this_actor.exec_init()`,
539       :py:func:`simgrid.Exec.start()`,
540       :py:func:`simgrid.Exec.wait()`,
541       :py:attr:`simgrid.Exec.remaining`,
542       :py:attr:`simgrid.Exec.remaining_ratio`,
543       :py:func:`simgrid.this_actor.exec_async()` and
544       :py:func:`simgrid.Exec.cancel()`.
545
546    .. example-tab:: examples/c/exec-async/exec-async.c
547
548       See also :cpp:func:`sg_actor_exec_init()`,
549       :cpp:func:`sg_exec_start()`,
550       :cpp:func:`sg_exec_wait()`,
551       :cpp:func:`sg_exec_get_remaining()`,
552       :cpp:func:`sg_exec_get_remaining_ratio()`,
553       :cpp:func:`sg_actor_exec_async()` and
554       :cpp:func:`sg_exec_cancel()`,
555
556 Remote execution
557 ----------------
558
559 You can start executions on remote hosts, or even change the host on which they occur during their execution.
560 This is naturally not very realistic, but it's something handy to have.
561
562 .. tabs::
563
564    .. example-tab:: examples/cpp/exec-remote/s4u-exec-remote.cpp
565
566       See also :cpp:func:`simgrid::s4u::Exec::set_host()`.
567
568    .. example-tab:: examples/python/exec-remote/exec-remote.py
569
570       See also :py:attr:`simgrid.Exec.host`.
571
572    .. example-tab:: examples/c/exec-remote/exec-remote.c
573
574       See also :cpp:func:`sg_exec_set_host()`.
575
576 .. _s4u_ex_ptasks:
577
578 Parallel executions
579 -------------------
580
581 These objects are convenient abstractions of parallel
582 computational kernels that span over several machines, such as a
583 PDGEM and the other ScaLAPACK routines. Note that this only works
584 with the "ptask_L07" host model (``--cfg=host/model:ptask_L07``).
585
586 This example demonstrates several kinds of parallel tasks: regular
587 ones, communication-only (without computation), computation-only
588 (without communication), synchronization-only (neither
589 communication nor computation). It also shows how to reconfigure a
590 task after its start, to change the number of hosts it runs onto.
591 This allows simulating malleable tasks.
592
593 .. tabs::
594
595    .. example-tab:: examples/cpp/exec-ptask/s4u-exec-ptask.cpp
596
597       See also :cpp:func:`simgrid::s4u::this_actor::parallel_execute()`.
598
599    .. example-tab:: examples/python/exec-ptask/exec-ptask.py
600
601       See also :ref:`simgrid.this_actor.parallel_execute()`
602
603 Ptasks play well with the host energy plugin, as shown in this example.
604 There is not much new compared to the above ptask example or the
605 :ref:`examples about energy <s4u_ex_energy>`. It just works.
606
607 .. tabs::
608
609    .. example-tab:: examples/cpp/energy-exec-ptask/s4u-energy-exec-ptask.cpp
610
611    .. example-tab:: examples/c/energy-exec-ptask/energy-exec-ptask.c
612
613 .. _s4u_ex_exec_failure:
614
615 Dealing with host failures
616 --------------------------
617
618 This examples shows how to survive to host failure exceptions that occur when an host is turned off. The actors do not get notified when the host
619 on which they run is turned off: they are just terminated in this case, and their ``on_exit()`` callback gets executed. For remote executions on
620 failing hosts however, any blocking operation such as ``exec`` or ``wait`` will raise an exception that you can catch and react to. See also
621 :ref:`howto_churn`,
622 :ref:`this example <s4u_ex_platform_state_profile>` on how to attach a state profile to hosts, and
623 :ref:`that example <s4u_ex_comm_failure>` on how to react to networ failures.
624
625 .. tabs::
626
627    .. example-tab:: examples/cpp/exec-failure/s4u-exec-failure.cpp
628
629 .. _s4u_ex_dvfs:
630
631 DVFS and pstates
632 ----------------
633
634 This example shows how to define a set of pstates in the XML. The current pstate
635 of a host can then be accessed and changed from the program.
636
637 .. tabs::
638
639    .. example-tab:: examples/cpp/exec-dvfs/s4u-exec-dvfs.cpp
640
641       See also :cpp:func:`simgrid::s4u::Host::get_pstate_speed` and :cpp:func:`simgrid::s4u::Host::set_pstate`.
642
643    .. example-tab:: examples/c/exec-dvfs/exec-dvfs.c
644
645       See also :cpp:func:`sg_host_get_pstate_speed` and :cpp:func:`sg_host_set_pstate`.
646
647    .. example-tab:: examples/python/exec-dvfs/exec-dvfs.py
648
649       See also :py:func:`simgrid.Host.pstate_speed()` and :py:attr:`simgrid.Host.pstate`.
650
651    .. example-tab:: examples/platforms/energy_platform.xml
652
653       The important parts are in the :ref:`pf_tag_host` tag. The ``pstate`` attribute is the initial pstate while the ``speed`` attribute must
654       be a comma-separated list of values: the speed at each pstate. This platform file also describes the ``wattage_per_state`` and
655       ``wattage_off`` properties, that are used by the :ref:`plugin_host_energy` plugin.
656
657 .. _s4u_ex_disk_io:
658
659 I/O on Disks and Files
660 ======================
661
662 SimGrid provides two levels of abstraction to interact with the
663 simulated disks. At the simplest level, you simply create read and
664 write actions on the disk resources.
665
666 Access to raw disk devices
667 --------------------------
668
669 This example illustrates how to simply read and write data on a simulated disk resource.
670
671 .. tabs::
672
673    .. example-tab:: examples/cpp/io-disk-raw/s4u-io-disk-raw.cpp
674
675    .. example-tab:: examples/c/io-disk-raw/io-disk-raw.c
676
677    .. example-tab:: examples/platforms/hosts_with_disks.xml
678
679       This shows how to declare disks in XML.
680
681 Asynchronous raw accesses
682 -------------------------
683
684 As most other activities, raw IO accesses can be used asynchronously, as illustrated in this example.
685
686 .. tabs::
687
688    .. example-tab:: examples/cpp/io-async/s4u-io-async.cpp
689
690 Filesystem plugin
691 -----------------
692
693 The FileSystem plugin provides a more detailed view, with the
694 classical operations over files: open, move, unlink, and of course,
695 read and write. The file and disk sizes are also dealt with and can
696 result in short reads and short writes, as in reality.
697
698   - **File Management:**
699     This example illustrates the use of operations on files
700     (read, write, seek, tell, unlink, etc).
701
702     .. tabs::
703
704        .. example-tab:: examples/cpp/io-file-system/s4u-io-file-system.cpp
705
706        .. example-tab:: examples/c/io-file-system/io-file-system.c
707
708   - **Remote I/O:**
709     I/O operations on files can also be done remotely,
710     i.e. when the accessed disk is not mounted on the caller's host.
711
712     .. tabs::
713
714        .. example-tab:: examples/cpp/io-file-remote/s4u-io-file-remote.cpp
715
716        .. example-tab:: examples/c/io-file-remote/io-file-remote.c
717
718 .. _s4u_ex_dag:
719
720 DAG of activities
721 =================
722
723 SimGrid makes it easy to express dependencies between activities, where a given activity cannot start until the completion of all its predecessors.
724 You can even have simulation not involving any actors, where the main thread (called maestro) creates and schedules activities itself. 
725
726 Simple DAG of activities
727 ------------------------
728
729 This example shows how to create activities organized as a DAG (direct acyclic graph), and start them.
730
731 .. tabs::
732
733    .. example-tab:: examples/cpp/dag-simple/s4u-dag-simple.cpp
734
735 DAG with communication
736 ----------------------
737
738 This is a little example showing how add communication activities to your DAG, representing inter-task data exchanges.
739
740 .. tabs::
741
742    .. example-tab:: examples/cpp/dag-comm/s4u-dag-comm.cpp
743
744 DAG with I/O 
745 ------------
746
747 This is a little example showing how add I/O activities to your DAG, representing disk buffers.
748
749 .. tabs::
750
751    .. example-tab:: examples/cpp/dag-io/s4u-dag-io.cpp
752
753 Assigning activities
754 --------------------
755
756 To actually start, an activity needs to be assigned to a given resource. This examples illustrates how an execution that is not assigned will not actually start until being assigned.
757
758 .. tabs::
759
760    .. example-tab:: examples/cpp/exec-unassigned/s4u-exec-unassigned.cpp
761
762 Scheduling activities
763 ---------------------
764
765 This example illustrates a simple scheduling algorithm, where the activities are placed on the "most adapted" host. Of course, there is many way 
766 to determine which host is the better fit for a given activity, and this example just uses a simple algorithm.
767
768 .. tabs::
769
770    .. example-tab:: examples/cpp/dag-scheduling/s4u-dag-scheduling.cpp
771
772 Loading DAGs from file
773 ----------------------
774
775 There is currently two file formats that you can load directly in SimGrid, but writting another loader for your beloved format should not be difficult.
776
777 .. tabs::
778
779    .. example-tab:: examples/cpp/dag-from-dax/s4u-dag-from-dax.cpp
780
781    .. group-tab:: input
782
783       .. showfile:: examples/cpp/dag-from-dax/smalldax.xml
784          :language: xml
785
786 .. tabs::
787
788    .. example-tab:: examples/cpp/dag-from-dot/s4u-dag-from-dot.cpp
789
790    .. group-tab:: input
791
792       .. showfile:: examples/cpp/dag-from-dot/dag.dot
793          :language: xml
794
795 Simulating a time slice
796 -----------------------
797
798 When you declare activities, :cpp:func:`simgrid::s4u::Engine::run()` runs up to the point of time where an activity completes.
799 Sometimes, you want to give a maximal duration to simulate up to a given date at most, for example to inject a new activity at that time.
800 This example shows how to do it.
801
802 .. tabs::
803
804    .. example-tab:: examples/cpp/engine-run-partial/s4u-engine-run-partial.cpp
805
806 DAG and failures
807 ----------------
808
809 This example shows how to deal with host or network failures while scheduling DAGs of activities.
810
811 .. tabs::
812
813    .. example-tab:: examples/cpp/dag-failure/s4u-dag-failure.cpp
814
815 DAGs and actors
816 ---------------
817
818 You can also declare dependencies to regular activities that are executed by actors, as shown in the following examples. 
819 The first one declare dependencies between executions while the second one declare dependencies between communications. 
820 You could declare such dependencies between arbitrary activities.
821
822 .. tabs::
823
824    .. example-tab:: examples/cpp/exec-dependent/s4u-exec-dependent.cpp
825
826 .. tabs::
827
828    .. example-tab:: examples/cpp/comm-dependent/s4u-comm-dependent.cpp
829
830 .. _s4u_ex_IPC:
831
832 Classical synchronization objects
833 =================================
834
835 Barrier
836 -------
837
838 Shows how to use :cpp:type:`simgrid::s4u::Barrier` synchronization objects.
839
840 .. tabs::
841
842    .. example-tab:: examples/cpp/synchro-barrier/s4u-synchro-barrier.cpp
843
844    .. example-tab:: examples/python/synchro-barrier/synchro-barrier.py
845
846 Condition variable: basic usage
847 -------------------------------
848
849 Shows how to use :cpp:type:`simgrid::s4u::ConditionVariable` synchronization objects.
850
851 .. tabs::
852
853    .. example-tab:: examples/cpp/synchro-condition-variable/s4u-synchro-condition-variable.cpp
854
855 Condition variable: timeouts
856 ----------------------------
857
858 Shows how to specify timeouts when blocking on condition variables.
859
860 .. tabs::
861
862    .. example-tab:: examples/cpp/synchro-condition-variable-waituntil/s4u-synchro-condition-variable-waituntil.cpp
863
864 Mutex
865 -----
866
867 Shows how to use :cpp:type:`simgrid::s4u::Mutex` synchronization objects.
868
869 .. tabs::
870
871    .. example-tab:: examples/cpp/synchro-mutex/s4u-synchro-mutex.cpp
872
873    .. example-tab:: examples/python/synchro-mutex/synchro-mutex.py
874
875 Semaphore
876 ---------
877
878 Shows how to use :cpp:type:`simgrid::s4u::Semaphore` synchronization objects.
879
880 .. tabs::
881
882    .. example-tab:: examples/cpp/synchro-semaphore/s4u-synchro-semaphore.cpp
883
884    .. example-tab:: examples/python/synchro-semaphore/synchro-semaphore.py
885
886    .. example-tab:: examples/c/synchro-semaphore/synchro-semaphore.c
887
888 *****************************
889 Interacting with the Platform
890 *****************************
891
892 User-defined properties
893 =======================
894
895 You can attach arbitrary information to most platform elements from the XML file, and then interact with these values from your
896 program. Note that the changes are not written permanently on disk, in the XML file nor anywhere else. They only last until the end of
897 your simulation.
898
899 .. tabs::
900
901    .. example-tab:: examples/cpp/platform-properties/s4u-platform-properties.cpp
902
903       - :cpp:func:`simgrid::s4u::Actor::get_property()` and :cpp:func:`simgrid::s4u::Actor::set_property()`
904       - :cpp:func:`simgrid::s4u::Host::get_property()` and :cpp:func:`simgrid::s4u::Host::set_property()`
905       - :cpp:func:`simgrid::s4u::Link::get_property()` and :cpp:func:`simgrid::s4u::Link::set_property()`
906       - :cpp:func:`simgrid::s4u::NetZone::get_property()` and :cpp:func:`simgrid::s4u::NetZone::set_property()`
907
908    .. example-tab:: examples/c/platform-properties/platform-properties.c
909
910       - :cpp:func:`sg_actor_get_property_value()`
911       - :cpp:func:`sg_host_get_property_value()` and :cpp:func:sg_host_set_property_value()`
912       - :cpp:func:`sg_zone_get_property_value()` and :cpp:func:`sg_zone_set_property_value()`
913
914    .. group-tab:: XML
915
916       **Platform file:**
917
918       .. showfile:: examples/platforms/prop.xml
919          :language: xml
920
921 Element filtering
922 =================
923
924 Retrieving the netzones matching given criteria
925 -----------------------------------------------
926
927 Shows how to filter the cluster netzones.
928
929 .. tabs::
930
931    .. example-tab:: examples/cpp/routing-get-clusters/s4u-routing-get-clusters.cpp
932
933 Retrieving the list of hosts matching given criteria
934 ----------------------------------------------------
935
936 Shows how to filter the actors that match given criteria.
937
938 .. tabs::
939
940    .. example-tab:: examples/cpp/engine-filtering/s4u-engine-filtering.cpp
941
942 Profiles
943 ========
944
945 .. _s4u_ex_platform_state_profile:
946
947 Specifying state profiles
948 -------------------------
949
950 Shows how to specify when the resources must be turned off and on again, and how to react to such
951 failures in your code. See also :ref:`howto_churn`,
952 :ref:`this example <s4u_ex_comm_failure>` on how to react to communication failures, and
953 :ref:`that example <s4u_ex_exec_failure>` on how to react to host failures.
954
955 .. tabs::
956
957    .. example-tab:: examples/cpp/platform-failures/s4u-platform-failures.cpp
958
959    .. example-tab:: examples/c/platform-failures/platform-failures.c
960
961    .. example-tab:: examples/python/platform-failures/platform-failures.py
962
963    .. group-tab:: XML
964
965       .. showfile:: examples/platforms/small_platform_failures.xml
966          :language: xml
967
968       .. showfile:: examples/platforms/profiles/jupiter_state.profile
969
970       .. showfile:: examples/platforms/profiles/fafard_state.profile
971
972 Specifying speed profiles
973 -------------------------
974
975 Shows how to specify an external load to resources, variating their peak speed over time.
976
977    .. tabs::
978
979       .. example-tab:: examples/cpp/platform-profile/s4u-platform-profile.cpp
980
981       .. example-tab:: examples/python/platform-profile/platform-profile.py
982
983       .. group-tab:: XML
984
985          .. showfile:: examples/platforms/small_platform_profile.xml
986             :language: xml
987
988          .. showfile:: examples/platforms/profiles/jupiter_speed.profile
989
990          .. showfile:: examples/platforms/profiles/link1_bandwidth.profile
991
992          .. showfile:: examples/platforms/profiles/link1_latency.profile
993
994 Modifying the platform
995 ======================
996
997 Serializing communications
998 --------------------------
999
1000 This example shows how to limit the amount of communications going through a given link.
1001 It is very similar to the other asynchronous communication examples, but messages get serialized by the platform.
1002 Without this call to ``Link::set_concurrency_limit(2)``, all messages would be received at the exact same timestamp since
1003 they are initiated at the same instant and are of the same size. But with this extra configuration to the link, at most 2
1004 messages can travel through the link at the same time.
1005
1006 .. tabs::
1007
1008    .. example-tab:: examples/cpp/platform-comm-serialize/s4u-platform-comm-serialize.cpp
1009
1010       See also :cpp:func:`simgrid::s4u::Link::set_concurrency_limit()`.
1011
1012    .. example-tab:: examples/python/platform-comm-serialize/platform-comm-serialize.py
1013
1014       See also :py:func:`simgrid.Link.set_concurrency_limit()`.
1015
1016 .. _s4u_ex_energy:
1017
1018 *****************
1019 Energy Simulation
1020 *****************
1021
1022 Setup
1023 =====
1024
1025 Describing the energy profiles in the platform
1026 ----------------------------------------------
1027
1028 The first platform file contains the energy profile of each link and host for a wired network, which is necessary to get energy consumption
1029 predictions. The second platform file is the equivalent for a wireless network. As usual, you should not trust our example, and you should
1030 strive to double-check that your instantiation matches your target platform.
1031
1032 .. tabs::
1033
1034    .. group-tab:: XML
1035
1036 .. showfile:: examples/platforms/energy_platform.xml
1037    :language: xml
1038
1039 .. showfile:: examples/platforms/wifi_energy.xml
1040    :language: xml
1041
1042 Usage
1043 =====
1044
1045 CPU energy consumption
1046 ----------------------
1047
1048 This example shows how to retrieve the amount of energy consumed by the CPU during computations, and the impact of the pstate.
1049
1050 .. tabs::
1051
1052    .. example-tab:: examples/cpp/energy-exec/s4u-energy-exec.cpp
1053
1054    .. example-tab:: examples/c/energy-exec/energy-exec.c
1055
1056 Virtual machines consumption
1057 ----------------------------
1058
1059 This example is very similar to the previous one, adding VMs to the picture.
1060
1061 .. tabs::
1062
1063    .. example-tab:: examples/cpp/energy-vm/s4u-energy-vm.cpp
1064
1065    .. example-tab:: examples/c/energy-vm/energy-vm.c
1066
1067 Wired network energy consumption
1068 --------------------------------
1069
1070 This example shows how to retrieve and display the energy consumed by the wired network during communications.
1071
1072 .. tabs::
1073
1074    .. example-tab:: examples/cpp/energy-link/s4u-energy-link.cpp
1075
1076 WiFi network energy consumption
1077 -------------------------------
1078
1079 This example shows how to retrieve and display the energy consumed by the wireless network during communications.
1080
1081 .. tabs::
1082
1083    .. example-tab:: examples/cpp/energy-wifi/s4u-energy-wifi.cpp
1084
1085 Modeling the shutdown and boot of hosts
1086 ---------------------------------------
1087
1088 Simple example of a model for the energy consumption during the host boot and shutdown periods.
1089
1090 .. tabs::
1091
1092    .. example-tab:: examples/platforms/energy_boot.xml
1093
1094    .. example-tab:: examples/cpp/energy-boot/s4u-energy-boot.cpp
1095
1096 ***********************
1097 Tracing and Visualizing
1098 ***********************
1099
1100 Tracing can be activated by various configuration options which are illustrated in these examples. See also the
1101 :ref:`full list of options related to tracing <tracing_tracing_options>`.
1102 The following introduces  some option sets of interest that you may want to pass to your simulators.
1103
1104 .. todo::
1105    These tracing examples should be integrated in the examples to not duplicate the C++ files.
1106    A full command line to see the result in the right tool (vite/FrameSoc) should be given along with some screenshots.
1107
1108 Platform Tracing
1109 ================
1110
1111 Basic example
1112 -------------
1113
1114 This program is a toy example just loading the platform so that you can play with the platform visualization. Recommended options:
1115 ``--cfg=tracing:yes --cfg=tracing/categorized:yes``
1116
1117 .. tabs::
1118
1119    .. example-tab:: examples/cpp/trace-platform/s4u-trace-platform.cpp
1120
1121 Setting Categories
1122 ------------------
1123
1124 This example declares several tracing categories that are used to
1125 classify its tasks. When the program is executed, the tracing mechanism
1126 registers the resource utilization of hosts and links according to these
1127 categories. Recommended options:
1128 ``--cfg=tracing:yes --cfg=tracing/categorized:yes --cfg=tracing/uncategorized:yes``
1129
1130 .. tabs::
1131
1132    .. example-tab:: examples/cpp/trace-categories/s4u-trace-categories.cpp
1133
1134 Master Workers tracing
1135 ----------------------
1136
1137 This is an augmented version of our basic master/worker example using
1138 several tracing features. It traces resource usage, sorted out in several
1139 categories; Trace marks and user variables are also used. Recommended
1140 options: ``--cfg=tracing/categorized:yes --cfg=tracing/uncategorized:yes``
1141
1142 .. tabs::
1143
1144    .. example-tab:: examples/cpp/trace-masterworkers/s4u-trace-masterworkers.cpp
1145
1146    .. example-tab:: examples/python/app-masterworkers/app-masterworkers.py
1147
1148 Process migration tracing
1149 -------------------------
1150
1151 This version is enhanced so that the process migrations can be displayed
1152 as arrows in a Gantt-chart visualization. Recommended options to that
1153 extend: ``--cfg=tracing:yes --cfg=tracing/actor:yes``
1154
1155 .. tabs::
1156
1157    .. example-tab:: examples/cpp/trace-process-migration/s4u-trace-process-migration.cpp
1158
1159 Tracing user variables
1160 ======================
1161
1162 You can also attach your own variables to any resource described in the platform
1163 file. The following examples illustrate this feature.  They have to be run with
1164 the following options: ``--cfg=tracing:yes --cfg=tracing/platform:yes``
1165
1166 Attaching variables to Hosts
1167 ----------------------------
1168
1169 .. tabs::
1170
1171    .. example-tab:: examples/cpp/trace-host-user-variables/s4u-trace-host-user-variables.cpp
1172
1173 Attaching variables to Links
1174 ----------------------------
1175
1176 The tricky part is that you have to know the name of the link you want to enhance with a variable.
1177
1178 .. tabs::
1179
1180    .. example-tab:: examples/cpp/trace-link-user-variables/s4u-trace-link-user-variables.cpp
1181
1182 Attaching variables to network routes
1183 -------------------------------------
1184
1185 It is often easier to update a given variable for all links of a given network path (identified by its source and destination hosts) instead of
1186 knowing the name of each specific link.
1187
1188 .. tabs::
1189
1190    .. example-tab::  examples/cpp/trace-route-user-variables/s4u-trace-route-user-variables.cpp
1191
1192 ************************
1193 Larger SimGrid Exemplars
1194 ************************
1195
1196 This section contains application examples that are somewhat larger than the previous examples.
1197
1198 Classical examples
1199 ==================
1200
1201 Token ring
1202 ----------
1203
1204 Shows how to implement a classical communication pattern, where a token is exchanged along a ring to reach every participant.
1205
1206 .. tabs::
1207
1208    .. example-tab:: examples/cpp/app-token-ring/s4u-app-token-ring.cpp
1209
1210    .. example-tab:: examples/c/app-token-ring/app-token-ring.c
1211
1212 Master Workers
1213 --------------
1214
1215 Another good old example, where one Master actor has a bunch of tasks to dispatch to a set of several Worker actors.
1216 This example is used in the :ref:`SimGrid tutorial <usecase_simalgo>`.
1217
1218 .. tabs::
1219
1220    .. group-tab:: C++
1221
1222       This example comes in two equivalent variants, one where the actors
1223       are specified as simple functions (which is easier to understand for
1224       newcomers) and one where the actors are specified as classes (which is
1225       more powerful for the users wanting to build their own projects upon
1226       the example).
1227
1228       .. showfile:: examples/cpp/app-masterworkers/s4u-app-masterworkers-class.cpp
1229          :language: cpp
1230
1231       .. showfile:: examples/cpp/app-masterworkers/s4u-app-masterworkers-fun.cpp
1232          :language: cpp
1233
1234    .. group-tab:: C
1235
1236       .. showfile:: examples/c/app-masterworker/app-masterworker.c
1237          :language: cpp
1238
1239    .. example-tab:: examples/python/app-masterworkers/app-masterworkers.py
1240
1241 Data diffusion
1242 ==============
1243
1244 Bit Torrent
1245 -----------
1246
1247 Classical protocol for Peer-to-Peer data diffusion.
1248
1249 .. tabs::
1250
1251    .. group-tab:: C++
1252
1253       .. showfile:: examples/cpp/app-bittorrent/s4u-bittorrent.cpp
1254          :language: cpp
1255
1256       .. showfile:: examples/cpp/app-bittorrent/s4u-peer.cpp
1257          :language: cpp
1258
1259       .. showfile:: examples/cpp/app-bittorrent/s4u-tracker.cpp
1260          :language: cpp
1261
1262    .. group-tab:: C
1263
1264       .. showfile:: examples/c/app-bittorrent/app-bittorrent.c
1265          :language: cpp
1266
1267       .. showfile:: examples/c/app-bittorrent/bittorrent-peer.c
1268          :language: cpp
1269
1270       .. showfile:: examples/c/app-bittorrent/tracker.c
1271          :language: cpp
1272
1273 Chained Send
1274 ------------
1275
1276 Data broadcast over a ring of processes.
1277
1278 .. tabs::
1279
1280    .. example-tab:: examples/cpp/app-chainsend/s4u-app-chainsend.cpp
1281
1282    .. group-tab:: C
1283
1284       .. showfile:: examples/c/app-chainsend/chainsend.c
1285          :language: c
1286
1287       .. showfile:: examples/c/app-chainsend/broadcaster.c
1288          :language: c
1289
1290       .. showfile:: examples/c/app-chainsend/peer.c
1291          :language: c
1292
1293 Distributed Hash Tables (DHT)
1294 =============================
1295
1296 Chord Protocol
1297 --------------
1298
1299 One of the most famous DHT protocol.
1300
1301 .. tabs::
1302
1303    .. group-tab:: C++
1304
1305       .. showfile:: examples/cpp/dht-chord/s4u-dht-chord.cpp
1306          :language: cpp
1307
1308       .. showfile:: examples/cpp/dht-chord/s4u-dht-chord-node.cpp
1309          :language: cpp
1310
1311 Kademlia
1312 --------
1313
1314 Another well-known DHT protocol.
1315
1316 .. tabs::
1317
1318    .. group-tab:: C++
1319
1320       .. showfile:: examples/cpp/dht-kademlia/s4u-dht-kademlia.cpp
1321          :language: cpp
1322
1323       .. showfile:: examples/cpp/dht-kademlia/routing_table.cpp
1324          :language: cpp
1325
1326       .. showfile:: examples/cpp/dht-kademlia/answer.cpp
1327          :language: cpp
1328
1329       .. showfile:: examples/cpp/dht-kademlia/node.cpp
1330          :language: cpp
1331
1332    .. group-tab:: C
1333
1334       .. showfile:: examples/c/dht-kademlia/dht-kademlia.c
1335          :language: cpp
1336
1337       .. showfile:: examples/c/dht-kademlia/routing_table.c
1338          :language: cpp
1339
1340       .. showfile:: examples/c/dht-kademlia/answer.c
1341          :language: cpp
1342
1343       .. showfile:: examples/c/dht-kademlia/message.c
1344          :language: cpp
1345
1346       .. showfile:: examples/c/dht-kademlia/node.c
1347          :language: cpp
1348
1349 Pastry
1350 ------
1351
1352 Yet another well-known DHT protocol.
1353
1354 .. tabs::
1355
1356    .. example-tab:: examples/c/dht-pastry/dht-pastry.c
1357
1358 .. _s4u_ex_clouds:
1359
1360 Simulating Clouds
1361 =================
1362
1363 Cloud basics
1364 ------------
1365
1366 This example starts some computations both on PMs and VMs and migrates some VMs around.
1367
1368 .. tabs::
1369
1370    .. example-tab:: examples/cpp/cloud-simple/s4u-cloud-simple.cpp
1371
1372    .. example-tab:: examples/c/cloud-simple/cloud-simple.c
1373
1374 Migrating VMs
1375 -------------
1376
1377 This example shows how to migrate VMs between PMs.
1378
1379 .. tabs::
1380
1381    .. example-tab:: examples/cpp/cloud-migration/s4u-cloud-migration.cpp
1382
1383    .. example-tab:: examples/c/cloud-migration/cloud-migration.c
1384
1385 ***********************
1386 Model-Related Examples
1387 ***********************
1388
1389 ns-3 as a model
1390 ===============
1391
1392 This simple ping-pong example demonstrates how to use the bindings to the Network
1393 Simulator. The most interesting is probably not the C++ files since
1394 they are unchanged from the other simulations, but the associated files,
1395 such as the platform file to see how to declare a platform to be used
1396 with the ns-3 bindings of SimGrid and the tesh file to see how to
1397 start a simulation in these settings.
1398
1399 .. tabs::
1400
1401    .. example-tab:: examples/cpp/network-ns3/s4u-network-ns3.cpp
1402
1403    .. group-tab:: XML
1404
1405       **Platform files:**
1406
1407       .. showfile:: examples/platforms/small_platform_one_link_routes.xml
1408          :language: xml
1409
1410 WiFi links
1411 ==========
1412
1413 This demonstrates how to declare a wifi zone in your platform and
1414 how to use it in your simulation. For that, you should have a link
1415 whose sharing policy is set to `WIFI`. Such links can have more
1416 than one bandwidth value (separated by commas), corresponding to
1417 the several SNR level of your wifi link.
1418
1419 In this case, SimGrid automatically switches to validated
1420 performance models of wifi networks, where the time is shared
1421 between users instead of the bandwidth for wired links (the
1422 corresponding publication is currently being written).
1423
1424 If your wifi link provides more than one SNR level, you can switch
1425 the level of a given host using
1426 :cpp:func:`simgrid::s4u::Link::set_host_wifi_rate`. By default,
1427 the first level is used.
1428
1429 .. tabs::
1430
1431    .. example-tab:: examples/cpp/network-wifi/s4u-network-wifi.cpp
1432
1433    .. group-tab:: XML
1434
1435       **Platform files:**
1436
1437       .. showfile:: examples/platforms/wifi.xml
1438          :language: xml
1439
1440 You can also use the **ns-3 models on your wifi networks** as follows:
1441
1442 .. tabs::
1443
1444    .. example-tab:: examples/cpp/network-ns3-wifi/s4u-network-ns3-wifi.cpp
1445
1446    .. group-tab:: XML
1447
1448       **Platform files:**
1449
1450       .. showfile:: examples/platforms/wifi_ns3.xml
1451          :language: xml
1452
1453
1454 ***************
1455 Plugin Examples
1456 ***************
1457
1458 It is possible to extend SimGrid without modifying its internals by
1459 attaching code to the existing signals and by adding extra data to the
1460 simulation objects through extensions. How to do that is not exactly
1461 documented yet, and you should look for examples in the src/plugins
1462 directory.
1463
1464 This section documents how the existing plugins can be used. Remember
1465 that you are very welcome to modify the plugins to fit your needs. It
1466 should be much easier than modifying the SimGrid kernel.
1467
1468 Monitoring the host load
1469 ========================
1470
1471 .. tabs::
1472
1473    .. example-tab:: examples/cpp/plugin-host-load/s4u-plugin-host-load.cpp
1474
1475    .. example-tab:: examples/c/plugin-host-load/plugin-host-load.c
1476
1477 Monitoring the link load
1478 ========================
1479
1480 .. tabs::
1481
1482    .. example-tab:: examples/cpp/plugin-link-load/s4u-plugin-link-load.cpp
1483
1484 ***********************
1485 Model-Checking Examples
1486 ***********************
1487
1488 The model-checker can be used to exhaustively search for issues in the tested application. It must be activated at compile-time, but this
1489 mode is rather experimental in SimGrid (as of v3.25). We are working on it :)
1490
1491 Failing assert
1492 ==============
1493
1494 In this example, two actors send some data to a central server, which asserts that the messages are always received in the same order.
1495 This is wrong, and the model-checker correctly finds a counter-example to that assertion.
1496
1497 .. tabs::
1498
1499    .. example-tab:: examples/cpp/mc-failing-assert/s4u-mc-failing-assert.cpp
1500
1501 .. |br| raw:: html
1502
1503    <br />