========================================================================
-En mode entier (-Z), aucune vérification n'est faite sur la charge
-totale, ni sur la répartition initiale!
+-- Wed, Feb 29 16:16:45 2012 +0100
-Il faut vérifier, et arrondir et émettre un warning dans le cas contraire :
-- que la charge totale est entière, dans main.cpp ;
-- au début de chaque process que la charge initiale est entière.
-
-Il faut également s'assurer que la répartition aléatoire produit une
-distribution entière.
+Les exécutions parallèles donnent des résultats différents.
+Pourquoi ?
========================================================================
-##### RESOLVED BUGS COME AFTER THIS ####################################
+##### MOSTLY RESOLVED BUGS COME AFTER THIS #############################
========================================================================
+-- Mon, Feb 27 13:26:08 2012 +0100
+
+Les variables globales process::total_load_* ne sont pas protégées
+contre les accès concurrents. Il n'est donc pas possible actuellement
+d'exécuter les simulations en parallèle (--cfg=contexts/nthreads).
+
+-- Wed, Feb 29 15:54:31 2012 +0100
+
+Corrigé en partie. Il reste quelques "fixme: get locked?" à régler
+(ou pas).
+
+========================================================================
+-- Fri, May 20 17:01:33 2011 +0200
+
Il faut réviser l'utilisation du mutex entre le thread d'équilibrage
et le thread de calcul. Il semble gardé beaucoup trop longtemps.
+-- Tue, May 24 14:55:59 2011 +0200
+
Bon, une partie du problème est rectifiée par le commit
48de954 Stop locking the mutex on data_receive.
load, to_send et debt.
========================================================================
-Comment expliquer ces différences entre SG 3.5 et SG svn ?
-
-$ ./loba platform.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD
-[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data
-[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data
-[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data
-[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data
-[Fafard 2579.229566] [comm/DEBUG] received LOAD: 366.211 from Bourassa
-[Fafard 2605.989948] [comm/DEBUG] received LOAD: 20.0806 from Bourassa
-[Fafard 2612.318155] [comm/DEBUG] received LOAD: 4.74548 from Bourassa
-[Fafard 2616.450666] [comm/DEBUG] received LOAD: 3.09753 from Bourassa
-
-$ ./loba-dev platform_dev.xml -Tline -abest -L500 -t1800 -c1e8,0 -C1e7,0 -M0 2>&1 --log=comm.thres:debug -s100 -b | grep LOAD
-[Bourassa 1031.097913] [comm/DEBUG] send LOAD: 366.211 to Fafard_data
-[Bourassa 1306.997159] [comm/DEBUG] send LOAD: 20.0806 to Fafard_data
-[Fafard 1519.035900] [comm/DEBUG] received LOAD: 366.211 from Bourassa
-[Fafard 1519.035900] [comm/DEBUG] send LOAD: 282.074 to Ginette_data
-[Bourassa 1541.486345] [comm/DEBUG] send LOAD: 4.74548 to Fafard_data
-[Fafard 1629.312931] [comm/DEBUG] received LOAD: 20.0806 from Bourassa
-[Fafard 1629.312931] [comm/DEBUG] received LOAD: 4.74548 from Bourassa
-[Fafard 1629.312931] [comm/DEBUG] send LOAD: 6.19507 to Ginette_data
-[Bourassa 1766.189415] [comm/DEBUG] send LOAD: 3.09753 to Fafard_data
-[Fafard 1898.705676] [comm/DEBUG] received LOAD: 3.09753 from Bourassa
-[Ginette 1932.076243] [comm/DEBUG] received LOAD: 282.074 from Fafard
-[Ginette 1940.343540] [comm/DEBUG] received LOAD: 6.19507 from Fafard
-
-Probablement par un bug dans SG 3.5.
-
-========================================================================
-Il semblerait qu'il y ait un bug dans SG 3.5, et qu'on ne puisse pas
-utiliser MSG_comm_waitany() pour l'émetteur *et* le récepteur sans
-risquer d'interblocage.
-
-Le problème devrait être contourné correctement depuis le commit
-cd6b253 Use MSG_comm_waitall for communicator::flush(true).
+-- Tue, Apr 19 17:48:39 2011 +0200
-========================================================================
-Avec SG 3.5, les communications doivent être détruites dès que
-possible avec MSG_comm_destroy(). Si ce n'est pas fait, la simulation
-peut être extrêmement ralentie.
-
-Le problème devrait être contourné correctement depuis le commit
-404a8d5 Do not call flush automatically in communcator::send...
-
-========================================================================
Valgrind détecte une fuite de mémoire liée à un appel à backtrace.
Le problème semble être indépendant de SimGrid et peut être reproduit
