X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/809e5d6dcb4454e7200e329be127cf9bc67d2fa4..6a9d0cb70ec8497d66b6e7f95f2a08b5a2cf8da9:/src/simix/smx_global.c diff --git a/src/simix/smx_global.c b/src/simix/smx_global.c index 7f0f9ede1a..eb2a14180f 100644 --- a/src/simix/smx_global.c +++ b/src/simix/smx_global.c @@ -12,6 +12,7 @@ #include "xbt/ex.h" /* ex_backtrace_display */ #include "mc/mc.h" +XBT_LOG_NEW_CATEGORY(simix, "All SIMIX categories"); XBT_LOG_NEW_DEFAULT_SUBCATEGORY(simix_kernel, simix, "Logging specific to SIMIX (kernel)"); @@ -58,15 +59,6 @@ void SIMIX_global_init(int *argc, char **argv) s_smx_process_t proc; if (!simix_global) { - /* Connect our log channels: that must be done manually under windows */ - XBT_LOG_CONNECT(simix_deployment, simix); - XBT_LOG_CONNECT(simix_environment, simix); - XBT_LOG_CONNECT(simix_host, simix); - XBT_LOG_CONNECT(simix_kernel, simix); - XBT_LOG_CONNECT(simix_process, simix); - XBT_LOG_CONNECT(simix_synchro, simix); - XBT_LOG_CONNECT(simix_context, simix); - simix_global = xbt_new0(s_smx_global_t, 1); simix_global->process_to_run = xbt_dynar_new(sizeof(smx_process_t), NULL); @@ -173,6 +165,19 @@ XBT_INLINE double SIMIX_get_clock(void) } } +static int process_syscall_color(void *p) +{ + switch ((*(smx_process_t *)p)->simcall.call) { + case SIMCALL_NONE: + case SIMCALL_PROCESS_KILL: + return 2; + case SIMCALL_PROCESS_RESUME: + return 1; + default: + return 0; + } +} + void SIMIX_run(void) { double time = 0; @@ -192,7 +197,63 @@ void SIMIX_run(void) while (!xbt_dynar_is_empty(simix_global->process_to_run)) { XBT_DEBUG("New Sub-Schedule Round; size(queue)=%lu", xbt_dynar_length(simix_global->process_to_run)); + + /* Run all processes that are ready to run, possibly in parallel */ SIMIX_process_runall(); + + /* Move all killing processes to the end of the list, because killing a process that have an ongoing simcall is a bad idea */ + xbt_dynar_three_way_partition(simix_global->process_that_ran, process_syscall_color); + + /* answer sequentially and in a fixed arbitrary order all the simcalls that were issued during that sub-round */ + + /* WARNING, the order *must* be fixed or you'll jeopardize the simulation reproducibility (see RR-7653) */ + + /* Here, the order is ok because: + * - 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). + * 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 + * in arbitrary order (inductive hypothesis), we are fine. + * - If a process is added because it's getting killed, its subsequent actions shouldn't matter + * - 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. + * - 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: + * set = model->states.failed_action_set; + * while ((action = xbt_swag_extract(set))) + * SIMIX_simcall_post((smx_action_t) action->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 actions are + * poped out of the swag does not depend on the user code's execution order. + * - because the communication terminated. In this case, actions are served in the order given by + * set = model->states.done_action_set; + * while ((action = xbt_swag_extract(set))) + * SIMIX_simcall_post((smx_action_t) action->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, 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. + * 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). + * That would thus be a pure waste of time. + */ + xbt_dynar_foreach(simix_global->process_that_ran, iter, process) { if (process->simcall.call != SIMCALL_NONE) { SIMIX_simcall_pre(&process->simcall, 0);