examples/msg/trace-platform/trace-platform
examples/msg/trace-host-user-variables/trace-host-user-variables
examples/s4u/app-masterworker/s4u_app-masterworker
+examples/s4u/app-pingpong/s4u_app-pingpong
examples/s4u/app-token-ring/s4u_app-token-ring
examples/s4u/actions-comm/s4u_actions-comm
examples/s4u/actions-storage/s4u_actions-storage
- @ref msg_ex_models
- @ref msg_ex_ns3
- @ref msg_ex_io
- - @ref msg_ex_actions
- @ref msg_ex_apps
- @ref msg_ex_misc
-
+
@section msg_ex_basics Basic examples and features
- <b>Ping Pong</b>: @ref examples/msg/app-pingpong/app-pingpong.c\n
It's hard to think of a simpler example: it is just sending one
message back and forth.
The tesh file laying in the directory show how to start the
- simulator binary, enlighting how to pass options to the simulators
+ simulator binary, highlighting how to pass options to the simulators
(as detailed in Section \ref options).
- <b>Token Ring</b>.
I/O operations can also be done in a remote, i.e. when the
accessed disk is not mounted on the caller's host.
-@section msg_ex_actions Following Workload Traces
-
-This section details how to run trace-driven simulations. It is very
-handy when you want to test an algorithm or protocol that only react
-to external events. For example, many P2P protocols react to user
-requests, but do nothing if there is no such event.
-
-In such situations, you should write your protocol in C, and separate
-the workload that you want to play onto your protocol in a separate
-text file. Declare a function handling each type of the events in your
-trace, register them using @ref xbt_replay_action_register in your
-main, and then use @ref MSG_action_trace_run to launch the simulation.
-
-Then, you can either have one trace file containing all your events,
-or a file per simulated process: the former may be easier to work
-with, but the second is more efficient on very large traces. Check
-also the tesh files in the example directories for details.
-
- - <b>Communication replay</b>.
- @ref examples/msg/actions-comm/actions-comm.c \n
- Presents a set of event handlers reproducing classical communication
- primitives (synchronous and asynchronous send/receive, broadcast,
- barrier, etc).
-
- - <b>I/O replay</b>.
- @ref examples/msg/actions-storage/actions-storage.c \n
- Presents a set of event handlers reproducing classical I/O
- primitives (open, read, write, close, etc).
-
-
@section msg_ex_misc Miscellaneous
- <b>Task priorities</b>.
/**
-@example examples/msg/app-pingpong/app-pingpong.c
-@example examples/msg/app-token-ring/app-token-ring.c
+@example examples/msg/app-pingpong/app-pingpong.c
+@example examples/msg/app-token-ring/app-token-ring.c
@example examples/msg/app-masterworker/app-masterworker.c
@example examples/msg/async-wait/async-wait.c
@example examples/msg/io-file/io-file.c
@example examples/msg/io-remote/io-remote.c
-@example examples/msg/actions-comm/actions-comm.c
-@example examples/msg/actions-storage/actions-storage.c
-
@example examples/msg/task-priority/task-priority.c
@example examples/msg/platform-properties/platform-properties.c
-
+
*/
@ref examples/s4u/actor-create/s4u_actor-create_d.xml \n
Shows how to start your actors to populate your simulation.
+ - <b>Ping Pong</b>: @ref examples/s4u/app-pingpong/s4u_app-pingpong.c\n
+ It's hard to think of a simpler example: it is just sending one message back and forth.
+ The tesh file laying in the directory show how to start the simulator binary, highlighting how to pass options to
+ the simulators (as detailed in Section \ref options).
+
- <b>Token ring:</b> @ref examples/s4u/app-token-ring/s4u_app-token-ring.cpp \n
Shows how to implement a classical communication pattern, where a token is exchanged along a ring to reach every
participant.
@ref examples/s4u/actor-create/s4u_actor-create.cpp \n
Most actors are started from the deployment XML file, but they exist other methods.
+ - <b>Daemonize actors</b>
+ @ref examples/s4u/actor-daemon/s4u_actor-daemon.cpp \n
+ Some actors may be intended to simulate daemons that run in background. This example show how to transform a regular
+ actor into a daemon that will be automatically killed once the simulation is over.
+
- <b>Suspend and Resume actors</b>.
@ref examples/s4u/actor-suspend/s4u_actor-suspend.cpp \n
Actors can be suspended and resumed during their executions
@example examples/s4u/actions-storage/s4u_actions-storage.cpp
@example examples/s4u/actor-create/s4u_actor-create.cpp
@example examples/s4u/actor-create/s4u_actor-create_d.xml
+@example examples/s4u/actor-daemon/s4u_actor-daemon.cpp
@example examples/s4u/actor-kill/s4u_actor-kill.cpp
@example examples/s4u/actor-migration/s4u_actor-migration.cpp
@example examples/s4u/actor-suspend/s4u_actor-suspend.cpp
@example examples/s4u/app-token-ring/s4u_app-token-ring.cpp
@example examples/s4u/app-masterworker/s4u_app-masterworker.cpp
+@example examples/s4u/app-pingpong/s4u_app-pingpong.cpp
@example examples/s4u/mutex/s4u_mutex.cpp
*/
smx_timer_t SIMIX_timer_set(double date, void (*callback)(void*), void *arg)
{
- smx_timer_t timer = new s_smx_timer_t(date, [=](){ callback(arg); });
+ smx_timer_t timer = new s_smx_timer_t(date, [callback, arg]() { callback(arg); });
xbt_heap_push(simix_timers, timer, date);
return timer;
}
if (boost::dynamic_pointer_cast<simgrid::kernel::activity::IoImpl>(process->waiting_synchro) != nullptr)
synchro_description = "I/O";
-
- /*
- switch (process->waiting_synchro->type) {
- case SIMIX_SYNC_PARALLEL_EXECUTE:
- synchro_description = "parallel execution";
- break;
-
- case SIMIX_SYNC_JOIN:
- synchro_description = "joining";
- break;
-*/
-
XBT_INFO("Process %lu (%s@%s): waiting for %s synchro %p (%s) in state %d to finish", process->pid,
process->cname(), process->host->getCname(), synchro_description, process->waiting_synchro.get(),
process->waiting_synchro->name.c_str(), (int)process->waiting_synchro->state);