m

1
méthodologie5rappels sur le multi-threading

• caractéristiques générales
• commutation de thread
• grain de divisibilité
• synchroniser, cest retarder
• synchronisation et scheduling
• un problème méthodologique difficile
• quelques règles méthodologiques

2
rappels généraux caractéristiques générales
pile dexécution
compteur ordinal
code exécutable
mémoire centrale partagée

• caractéristiques essentielles
• une application peut comporter plusieurs threads
• les threads dune même application partagent le
  même espace mémoire
• chaque thread détermine une exécution
  séquentielle
• chaque thread est associé à une pile dexécution
  propre (attention coûteux !)

• dans le contexte de Net sous Windows
• les threads sont gérés par le système
• le système est maître des commutations
  (commutation préemptive)
• parallélisme vrai ou quasi-parallélisme

3
rappels généraux commutation de thread sur un
processeur
registre compteur ordinal
registre sommet de pile dexécution
1
2
contexte du thread A
contexte du thread B

• (1) arrêt du thread A
• sauvegarde du compteur ordinal
• sauvegarde du registre sommet de pile

• (2) reprise du thread B
• restauration du registre sommet de pile
• restauration du compteur ordinal

4
rappels généraux grain de divisibilité

• hypothèse dindivisibilité
• quasi parallélisme au niveau de linstruction
  machine
• vrai parallélisme au niveau de laccès à la
  mémoire

5
rappels généraux synchroniser, cest retarder
a1 ltlt a2
b1 ltlt b2
b2 doit attendre que a2 se soit exécutée
contrainte on veut que a2 précède toujours b2
6
rappels généraux synchronisation et scheduling
synchronisation
scheduling
éliminer les historiques dexécution non
souhaitables
choisirun historique dexécution parmi les
historiques souhaitables

• indépendance par rapport au temps  réel 
• filtrage des historiques dexécutions
• problèmes de précédence

• problèmes de performance
• problèmes de répartition sur les processeurs
• problèmes de priorités

7
rappels généraux les étreintes mortelles
attendre que A soit libresapproprier
Aattendre que B soit libresapproprier
Blibérer Alibérer B
attendre que B soit libresapproprier
Battendre que A soit libresapproprier
Alibérer Alibérer B
!

• deux (ou plus) threads sattendent les uns les
  autres
• les threads sont inter-bloqués
• pour certains historiques dexécution

8
un problème méthodologique difficile
hmmmm
programmer sûr(e) de soi,correctement, et du
premier coup

• effets agaçants des bogues de synchronisation
• plantages aléatoires (de temps en temps)
• conditions difficilement reproductibles

• inefficience des procédures de test
• tests exhaustifs encore plus impossibles
• les tests ne garantissent à peu près rien

9
règle -1 de la nécessité
êtes-vous bien sûr(e) quil ny a pas dautre
solution quune solution multi threads ?

• juste une question préalable

10
règle 1 des hypothèses certaines et minimales
?

• une synchronisation doit être  exacte 
• ne choisir que des hypothèses certaines
• ne pas jouer sur les particularités
  dimplémentation

• choisir les hypothèses  minimales 
• les plus générales (assertions universelles)
• les plus simples

11
règle 2 minimiser les risques de conflits

• pour tout emplacement partagé par plusieurs
  threads
• déterminer sil y a (ou non) risque dhistoriques
  indésirables
• si oui synchroniser convenablement laccès

12
règle 3 du confinement et de la localisation
ceci est un commentaire
// séquence critique de modification
mutex.Lock try criticalValue
finally mutex.Unlock end try

• confinement partout où cest possible
• confiner les problèmes de multi-threading
• éviter la dissémination des risques de conflits
• isolez le plus possible lihm et les threads

• programmer de manière locale
• séquences synchronisées courtes
• programmation claire et maîtrisable
•  dégraissez  les séquences synchronisées
• évitez les emboîtements de synchronisation

confiner localiser ? minimiser et identifier
les points dinteraction
blocs protégés (tryfinally) impératifs pour les
séquences critiques
13
règle 4 tout événement attendu doit arriver
?

• conséquences pratiques
• séquences critiques dans des blocs protégés
• dispositifs de délais dattente maximaux
• commandes utilisateur de sortie des attentes
• etc.

14
règle 5 de la terminaison correcte
?

• terminaison correcte dun système de threads
• dans le cas  normal 
• dans les cas  anormaux 

• cest souvent un problème dattentes multiples
• complication de la synchronisation et de la
  programmation
• requiert une gestion soignée des exceptions

15
règle 6 pas de bricolage
une application mal synchronisée est inutilisable

• réduire le problème en amont
• réduire la complexité des interactions
• réduire le nombre de points dinteractions
• énoncer clairement les modalités dinteraction

• soigner la programmation en aval
• utiliser des outils de synchronisation appropriés
• rechercher les synchronisations minimales
• éviter tout bricolage ou expédient