Mardi 11 Mars

Accueil - Dimanche - Lundi - Mardi - Mercredi - Jeudi - Vendredi

Matin

Conférence de Rachid Guerraoui (EPFL Lausanne - Suisse): "Transactional Memory : Principles"
Tout commence ici avec la fameuse loi de Moore qui énonce que le nombre de transistors des microprocesseurs sur une puce de silicium double tous les deux ans. Aujourd'hui on ne multiplie plus le nombre de transistors mais le nombre de coeurs. De cette configuration architecturale découle toute une flopée de problèmes liés à la communication entre les coeurs d'un même processeur. C'est sur cette problématique que s'inscrit cette présentation.
Rachid nous rappelle un titre d'article du New York Times du 7 Mai 2004 dans lequel Intel annonçait : Multicore is THE way to boost performance. Autrement dit : "Travailler plus pour gagner plus". En effet, pour utiliser les processeurs multicore, il faut plus de threads et plus de parallélisme. On souhaite donc un contrôle concurrentiel abstrait qui soit simple est efficace.
Que doit-on attendre de tout cela ?

• sécurité
• continuité de service (liveness)
• performance

Sécurité
Les transactions sont séquentielles et asynchrones. Pour tester la sécurité d'une transaction on crée un graphe dans lequel les noeuds sont les transactions et les arêtes sont les conflits entre les transactions. Si le graphe résultant est acyclique, on peut alors séquentialliser toutes les transactions.

Liveness
Fixons tout d'abord le vocabulaire. On parle de Liveness d'une implémentation ET de sécurité d'un objet. Une transaction doit faire des progrès, elle doit finir par commiter sauf si elle échoue. Il faut alors définir ce qu'est une transaction correcte. Est-ce qu'une transaction correcte doit commiter ? Le réponse est Non. Par contre seules les transactions non-correctes échouent. L'idéal serait d'avoir des transactions Wait-Free. Seulement c'est impossible, les personnes qui revendiquent ce dernier point utilisent des astuces comme le temps et les timeout.

Performance
AVSTM surpasse tous les autres Logiciels de Transaction (STM : Software Transactional Memory) lorsqu'il y a beaucoup de contention.

Le fin mot de l'histoire étant : Transactional Mermory is another proof of the irrelevance of the notion of relevance (libre interprétation de chacun).

Après Midi

Conditions météo : nuageux, fort vent en altitude avec fortes chutes de neige.
Enneigement : de la neige de la neige à ne plus savoir quoi en faire !

Hey regardez, le Mont-Blanc, le vrai, l'unique, le magnifique ... oui bon je sais il y a un nuage qui le cache mais ça joue en sa faveur. Le Mont-Blanc sait se faire attendre. Malheureusement on a attendu jusqu'au dernier jour et il ne nous a toujours pas montré son pic !

Soirée

Conférence de Pascal Felber (IIUN Neuchâtel - Suisse): "Transactional Memory : Practices"
Nous poursuivons ici dans la problématique des transactions. La notion d'"obstruction freedom" pourrait être définie comme suit : "Chaque thread qui fonctionne de manière autonome depuis assez longtemps fait des progrès". Celle de "lock freedom" pourrait être défini comme suit : "Certains threads font des progrès".
Différents logiciels permettent de faire des transactions :

• DSTM
• AXM
• FSTM
• LSA-STM

Pour plus de détails sur tous ces logiciels et bien d'autres suivez le lien.

Pour finir, Pascal présente un STM fait maison : TinySTM.

Cette deuxième journée se termine. Elle a été marquée par les vifs débats entre Rachid Guerraoui, Pascal Felber et Ken Birman.