X-Git-Url: http://bilbo.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/a6e4a812f0edc58eeb342f0c990122eabf51e6ec..2b564f86aa3a75bc55e6610087f79145019708b2:/src/kernel/EngineImpl.cpp diff --git a/src/kernel/EngineImpl.cpp b/src/kernel/EngineImpl.cpp index 3c136181c7..1e669cbab9 100644 --- a/src/kernel/EngineImpl.cpp +++ b/src/kernel/EngineImpl.cpp @@ -50,15 +50,6 @@ xbt_dynar_t get_actors_addr() #endif } -xbt_dynar_t get_dead_actors_addr() -{ -#if SIMGRID_HAVE_MC - return EngineImpl::get_instance()->get_dead_actors_vector(); -#else - xbt_die("This function is intended to be used when compiling with MC"); -#endif -} - constexpr std::initializer_list> context_factories = { #if HAVE_RAW_CONTEXTS {"raw", &context::raw_factory}, @@ -203,7 +194,6 @@ EngineImpl::~EngineImpl() /* Free the remaining data structures */ #if SIMGRID_HAVE_MC xbt_dynar_free(&actors_vector_); - xbt_dynar_free(&dead_actors_vector_); #endif /* clear models before freeing handle, network models can use external callback defined in the handle */ models_prio_.clear(); @@ -531,9 +521,6 @@ void EngineImpl::empty_trash() XBT_DEBUG("Getting rid of %s (refcount: %d)", actor->get_cname(), actor->get_refcount()); intrusive_ptr_release(actor); } -#if SIMGRID_HAVE_MC - xbt_dynar_reset(dead_actors_vector_); -#endif } void EngineImpl::display_all_actor_status() const @@ -736,60 +723,21 @@ void EngineImpl::run(double max_date) /* 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. - * - * Long proof: actors remain sorted through an arbitrary (implicit, complex but fixed) order in all cases. - * - * - 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. + * 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: * - * So science works, bitches [http://xkcd.com/54/]. + * - 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/). * - * 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_) {