X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/1bd1bbd35034c2e93a030a676dc244ad2cf74c70..9a357964cfeb78bcb01d5db716c8abaac1b47c43:/src/simix/smx_global.cpp diff --git a/src/simix/smx_global.cpp b/src/simix/smx_global.cpp index ad2d351fa1..a5f316f2d6 100644 --- a/src/simix/smx_global.cpp +++ b/src/simix/smx_global.cpp @@ -1,4 +1,4 @@ -/* Copyright (c) 2007-2017. The SimGrid Team. All rights reserved. */ +/* Copyright (c) 2007-2018. 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. */ @@ -11,7 +11,6 @@ #include /* Signal handling */ #include -#include #include #include @@ -210,9 +209,6 @@ void SIMIX_global_init(int *argc, char **argv) if (not simix_global) { simix_global = std::unique_ptr(new simgrid::simix::Global()); - - simgrid::simix::ActorImpl proc; - simix_global->process_to_destroy = xbt_swag_new(xbt_swag_offset(proc, destroy_hookup)); simix_global->maestro_process = nullptr; simix_global->create_process_function = &SIMIX_process_create; simix_global->kill_process_function = &kill_process; @@ -300,14 +296,14 @@ void SIMIX_clean() /* Free the remaining data structures */ simix_global->process_to_run.clear(); simix_global->process_that_ran.clear(); - xbt_swag_free(simix_global->process_to_destroy); + simix_global->process_to_destroy.clear(); simix_global->process_list.clear(); - simix_global->process_to_destroy = nullptr; xbt_os_mutex_destroy(simix_global->mutex); simix_global->mutex = nullptr; #if SIMGRID_HAVE_MC xbt_dynar_free(&simix_global->actors_vector); + xbt_dynar_free(&simix_global->dead_actors_vector); #endif /* Let's free maestro now */ @@ -343,9 +339,9 @@ double SIMIX_get_clock() /** Wake up all processes waiting for a Surf action to finish */ static void SIMIX_wake_processes() { - surf_action_t action; - for (auto const& model : *all_existing_models) { + simgrid::kernel::resource::Action* action; + XBT_DEBUG("Handling the processes whose action failed (if any)"); while ((action = surf_model_extract_failed_action_set(model))) { XBT_DEBUG(" Handling Action %p",action); @@ -438,13 +434,15 @@ void SIMIX_run() /* Here, the order is ok because: * - * Short proof: only maestro adds stuff to the process_to_run array, so the execution order of user contexts do not impact its order. + * Short proof: only maestro adds stuff to the process_to_run array, so the execution order of user contexts do + * not impact its order. * * Long proof: processes remain sorted through an arbitrary (implicit, complex but fixed) order in all cases. * * - if there is no kill during the simulation, processes remain sorted according by their PID. - * rational: This can be proved inductively. - * Assume that process_to_run is sorted at a beginning of one round (it is at round 0: the deployment file is parsed linearly). + * Rationale: This can be proved inductively. + * Assume that process_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 a process 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 @@ -453,37 +451,42 @@ void SIMIX_run() * - If a process gets added to process_to_run because one of their blocking action constituting the meat * of a simcall terminates, we're still good. Proof: * - You are added from SIMIX_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. + * kind (network, cpu, disk, whatever), but the same arguments hold. Let's take communications as an + * example. * - For communications, this function is called from SIMIX_comm_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: + * - 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 = xbt_swag_extract(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 - * poped out of the swag does not depend on the user code's execution order. + * poped 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 = xbt_swag_extract(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 SIMIX_comm_finish() do not depend on the order in which user processes are executed. - * So, in any cases, the orders of processes within process_to_run do not depend on the order in which user processes were executed previously. + * So, in any case, the orders of calls to SIMIX_comm_finish() do not depend on the order in which user + * processes are executed. + * So, in any cases, the orders of processes within process_to_run do not depend on the order in which + * user processes were executed previously. * So, if there is no killing in the simulation, the simulation reproducibility is not jeopardized. * - If there is some process 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. + * 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 process killing is perfectly reproducible. * * So science works, bitches [http://xkcd.com/54/]. * - * We could sort the process_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). + * We could sort the process_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. */ @@ -550,6 +553,7 @@ void SIMIX_run() XBT_CRITICAL("Oops ! Deadlock or code not perfectly clean."); SIMIX_display_process_status(); + simgrid::s4u::onDeadlock(); xbt_abort(); } simgrid::s4u::onSimulationEnd(); @@ -566,7 +570,7 @@ void SIMIX_run() */ 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]() { callback(arg); }); + smx_timer_t timer = new s_smx_timer_t(date, simgrid::xbt::makeTask([callback, arg]() { callback(arg); })); timer->handle_ = simix_timers.emplace(std::make_pair(date, timer)); return timer; }