X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/77bbf3027c4240a2e833209a3a3f186589da8577..5a9daf6dc6023e088fc54646fbe95de0bf872f2d:/src/simix/smx_global.cpp diff --git a/src/simix/smx_global.cpp b/src/simix/smx_global.cpp index ad2d351fa1..adcb65e55d 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 @@ -69,7 +68,7 @@ public: s_smx_timer_t(double date, simgrid::xbt::Task callback) : date(date), callback(std::move(callback)) {} }; -void (*SMPI_switch_data_segment)(int) = nullptr; +void (*SMPI_switch_data_segment)(simgrid::s4u::ActorPtr) = nullptr; int _sg_do_verbose_exit = 1; static void inthandler(int) @@ -170,21 +169,16 @@ static void kill_process(smx_actor_t process) SIMIX_process_kill(process, nullptr); } -static std::function maestro_code; namespace simgrid { namespace simix { simgrid::xbt::signal onDeadlock; -XBT_PUBLIC(void) set_maestro(std::function code) -{ - maestro_code = std::move(code); -} - } } +static std::function maestro_code; void SIMIX_set_maestro(void (*code)(void*), void* data) { #ifdef _WIN32 @@ -196,9 +190,6 @@ void SIMIX_set_maestro(void (*code)(void*), void* data) /** * \ingroup SIMIX_API * \brief Initialize SIMIX internal data. - * - * \param argc Argc - * \param argv Argv */ void SIMIX_global_init(int *argc, char **argv) { @@ -210,9 +201,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; @@ -224,7 +212,7 @@ void SIMIX_global_init(int *argc, char **argv) // Either create a new context with maestro or create // a context object with the current context mestro): - simgrid::simix::create_maestro(maestro_code); + simgrid::kernel::actor::create_maestro(maestro_code); /* Prepare to display some more info when dying on Ctrl-C pressing */ signal(SIGINT, inthandler); @@ -286,7 +274,7 @@ void SIMIX_clean() #endif /* Kill all processes (but maestro) */ - SIMIX_process_killall(simix_global->maestro_process, 1); + SIMIX_process_killall(simix_global->maestro_process); SIMIX_context_runall(); SIMIX_process_empty_trash(); @@ -300,14 +288,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 +331,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 +426,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 +443,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 +545,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 +562,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; } @@ -657,12 +653,12 @@ void SIMIX_display_process_status() if (boost::dynamic_pointer_cast(process->waiting_synchro) != nullptr) synchro_description = "I/O"; - XBT_INFO("Process %lu (%s@%s): waiting for %s synchro %p (%s) in state %d to finish", process->pid, + XBT_INFO("Process %ld (%s@%s): waiting for %s synchro %p (%s) in state %d to finish", process->pid, process->getCname(), process->host->getCname(), synchro_description, process->waiting_synchro.get(), process->waiting_synchro->name.c_str(), (int)process->waiting_synchro->state); } else { - XBT_INFO("Process %lu (%s@%s)", process->pid, process->getCname(), process->host->getCname()); + XBT_INFO("Process %ld (%s@%s)", process->pid, process->getCname(), process->host->getCname()); } } }