========================================================================
-- Wed, Feb 29 16:31:56 2012 +0100

Les fonctions MSG_get_host{number,table} n'existent plus dans les
dernières versions de SimGrid.  Utiliser MSG_hosts_as_dynar à la place.

========================================================================
-- Wed, Feb 29 16:16:45 2012 +0100

Les exécutions parallèles donnent des résultats différents.
Pourquoi ?

========================================================================
##### 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.

Pour le reste, je pense maintenant que ça ne gêne pas, au moins dans
le simulateur.  Pour faire bien, il faudrait plus séparer les deux
threads d'équilibrage et de calcul, et faire en sorte que chacun garde
un cache des données globales partagées.  Il suffirait alors de
synchroniser ces caches à chaque itération.

Les données partagées sont essentiellement les données des voisins :
load, to_send et debt.

========================================================================
-- Tue, Apr 19 17:48:39 2011 +0200

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
avec le code suivant (NB: l'équivalent, compilé avec gcc ne génère pas
d'erreur).
,----
| #include <execinfo.h>
| #include <iostream>
| int main()
| {
|     void *buffer[64];
|     int size = -1;
|     size = backtrace(buffer, sizeof buffer / sizeof buffer[0]);
|     std::cerr << "backtrace() returned " << size << "\n";
| }
`----
==532== HEAP SUMMARY:
==532==     in use at exit: 56 bytes in 1 blocks
==532==     ...
==532== LEAK SUMMARY:
==532==    ...
==532==    still reachable: 56 bytes in 1 blocks

========================================================================
-- Wed, Mar 9 08:24:40 2011 +0100

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

-- Thu, Mar 24 16:03:24 2011 +0100

Probablement par un bug dans SG 3.5.

========================================================================
-- Thu, Jan 27 17:15:02 2011 +0100

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).

========================================================================
-- Thu, Jan 27 17:15:02 2011 +0100

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...

========================================================================