-/* Copyright (c) 2016-2021. The SimGrid Team. All rights reserved. */
+/* Copyright (c) 2016-2022. The SimGrid Team. All rights reserved. */
/* This program is free software; you can redistribute it and/or modify it
* under the terms of the license (GNU LGPL) which comes with this package. */
#include "mc/mc.h"
#include "src/kernel/EngineImpl.hpp"
+#include "src/kernel/resource/StandardLinkImpl.hpp"
#include "src/kernel/resource/profile/Profile.hpp"
#include "src/mc/mc_record.hpp"
#include "src/mc/mc_replay.hpp"
#include "src/smpi/include/smpi_actor.hpp"
-#include "src/surf/network_interface.hpp"
#include "src/surf/xml/platf.hpp"
-#include "xbt/xbt_modinter.h" /* whether initialization was already done */
+#include "xbt/xbt_modinter.h" /* whether initialization was already done */
#include <boost/algorithm/string/predicate.hpp>
#ifndef _WIN32
/* register a function to be called by SURF after the environment creation */
sg_platf_init();
- s4u::Engine::on_platform_created.connect([this]() { this->presolve(); });
+ s4u::Engine::on_platform_created_cb([this]() { this->presolve(); });
if (config::get_value<bool>("debug/clean-atexit"))
atexit(shutdown);
/* List the actors and their state */
XBT_INFO("Legend of the following listing: \"Actor <pid> (<name>@<host>): <status>\"");
for (auto const& kv : actor_list_) {
- actor::ActorImpl* actor = kv.second;
+ const actor::ActorImpl* actor = kv.second;
if (actor->waiting_synchro_) {
const char* synchro_description = "unknown";
if (boost::dynamic_pointer_cast<kernel::activity::SleepImpl>(actor->waiting_synchro_) != nullptr)
synchro_description = "sleeping";
- if (boost::dynamic_pointer_cast<kernel::activity::RawImpl>(actor->waiting_synchro_) != nullptr)
+ if (boost::dynamic_pointer_cast<kernel::activity::SynchroImpl>(actor->waiting_synchro_) != nullptr)
synchro_description = "synchronization";
if (boost::dynamic_pointer_cast<kernel::activity::IoImpl>(actor->waiting_synchro_) != nullptr)
synchro_description = "I/O";
- XBT_INFO("Actor %ld (%s@%s): waiting for %s activity %#zx (%s) in state %d to finish", actor->get_pid(),
+ XBT_INFO("Actor %ld (%s@%s): waiting for %s activity %#zx (%s) in state %s to finish", actor->get_pid(),
actor->get_cname(), actor->get_host()->get_cname(), synchro_description,
(xbt_log_no_loc ? (size_t)0xDEADBEEF : (size_t)actor->waiting_synchro_.get()),
- actor->waiting_synchro_->get_cname(), (int)actor->waiting_synchro_->state_);
+ actor->waiting_synchro_->get_cname(), actor->waiting_synchro_->get_state_str());
} else {
XBT_INFO("Actor %ld (%s@%s) simcall %s", actor->get_pid(), actor->get_cname(), actor->get_host()->get_cname(),
SIMIX_simcall_name(actor->simcall_));
seal_platform();
if (MC_record_replay_is_active()) {
- mc::replay(MC_record_path());
+ mc::RecordTrace::replay(MC_record_path());
empty_trash();
return;
}
/* Here, the order is ok because:
*
- * Short proof: only maestro adds stuff to the actors_to_run array, so the execution order of user contexts do
- * not impact its order.
+ * Only maestro adds stuff to the actors_to_run array, so the execution order of user contexts do not impact its order.
+ *
+ * In addition, actors remain sorted through an arbitrary but fixed order in all cases:
*
- * Long proof: actors remain sorted through an arbitrary (implicit, complex but fixed) order in all cases.
+ * - If there is no killing during the simulation, actors remain sorted according by their PID.
+ * - Killer actors are moved to the end of the scheduling round (to let victims finish their simcall before dying), but
+ * (1) this decision of killing is reproducible because the simulation was reproducible until then
+ * (2) this reordering introduces no reproducibility hazard in the subsequent simulation.
+ * Even the order change induced by the actor killing is perfectly reproducible.
+ *
+ * So the array order is implicit and somewhat complex, but fixed and reproducible (science works, http://xkcd.com/54/).
*
- * - if there is no kill during the simulation, actors remain sorted according by their PID.
- * Rationale: This can be proved inductively.
- * Assume that actors_to_run is sorted at a beginning of one round (it is at round 0: the deployment file
- * is parsed linearly).
- * Let's show that it is still so at the end of this round.
- * - if an actor is added when being created, that's from maestro. It can be either at startup
- * time (and then in PID order), or in response to a process_create simcall. Since simcalls are handled
- * in arbitrary order (inductive hypothesis), we are fine.
- * - If an actor is added because it's getting killed, its subsequent actions shouldn't matter
- * - If an actor gets added to actors_to_run because one of their blocking action constituting the meat
- * of a simcall terminates, we're still good. Proof:
- * - You are added from ActorImpl::simcall_answer() only. When this function is called depends on the
- * resource kind (network, cpu, disk, whatever), but the same arguments hold. Let's take communications
- * as an example.
- * - For communications, this function is called from CommImpl::finish().
- * This function itself don't mess with the order since simcalls are handled in FIFO order.
- * The function is called:
- * - before the comm starts (invalid parameters, or resource already dead or whatever).
- * The order then trivial holds since maestro didn't interrupt its handling of the simcall yet
- * - because the communication failed or were canceled after startup. In this case, it's called from
- * the function we are in, by the chunk:
- * set = model->states.failed_action_set;
- * while ((synchro = extract(set)))
- * SIMIX_simcall_post((smx_synchro_t) synchro->data);
- * This order is also fixed because it depends of the order in which the surf actions were
- * added to the system, and only maestro can add stuff this way, through simcalls.
- * We thus use the inductive hypothesis once again to conclude that the order in which synchros are
- * popped out of the set does not depend on the user code's execution order.
- * - because the communication terminated. In this case, synchros are served in the order given by
- * set = model->states.done_action_set;
- * while ((synchro = extract(set)))
- * SIMIX_simcall_post((smx_synchro_t) synchro->data);
- * and the argument is very similar to the previous one.
- * So, in any case, the orders of calls to CommImpl::finish() do not depend on the order in which user
- * actors are executed.
- * So, in any cases, the orders of actors within actors_to_run do not depend on the order in which
- * user actors were executed previously.
- * So, if there is no killing in the simulation, the simulation reproducibility is not jeopardized.
- * - If there is some actor killings, the order is changed by this decision that comes from user-land
- * But this decision may not have been motivated by a situation that were different because the simulation is
- * not reproducible.
- * So, even the order change induced by the actor killing is perfectly reproducible.
- *
- * So science works, bitches [http://xkcd.com/54/].
- *
- * We could sort the actors_that_ran array completely so that we can describe the order in which simcalls are
- * handled (like "according to the PID of issuer"), but it's not mandatory (order is fixed already even if
- * unfriendly).
- * That would thus be a pure waste of time.
+ * We could manually sort the actors_that_ran array so that simcalls are handled in an easy to predict order
+ * (e.g. "according to the PID of issuer"), but it's not mandatory for the simulation soundness and reproducibility,
+ * and would thus be a pure waste of time.
*/
for (auto const& actor : actors_that_ran_) {
maestro_->kill(kv.second);
}
}
-
} while ((vetoed_activities == nullptr || vetoed_activities->empty()) &&
((elapsed_time > -1.0 && not double_equals(max_date, NOW, 0.00001)) || has_actors_to_run()));
