Thread – Coder proprement

Un thread doit :
– respecter le principe de responsabilité unique
– limiter la portée des données
– utiliser des copies des données
– être aussi indépendants que possible
– utliser des api qui sont safe thread

Il existe des modèles d’exécution :
Ressources bornées
Ressources dont la taille ou le nombre est figé et qui sont employées dans un environnement concurrent. Il s’agit, par exemple, des connexions à une base de données ou des tampons de lecture/écriture de taille fixe.

Exclusion mutuelle
Un seul thread à la fois peut accéder à des données ou à des ressources partagées.

Famine
Un thread ou un groupe de threads est interdit de fonctionnement pendant une durée excessivement longue ou indéfiniment. Par exemple, si les threads d’exécution courte sont toujours privilégiés, les threads dont le traitement est plus long peuvent ne jamais être élus si les premiers ne se terminent pas.

Interblocage (deadlock)
Deux threads ou plus attendent chacun la fin de l’autre. Chaque thread dispose d’une ressource dont l’autre a besoin et aucun ne peut se terminer tant qu’il n’a pas obtenu la ressource de l’autre.

Interblocage actif (livelock)
Les threads sont synchrones, chacun tentant de faire son travail mais rencontrant toujours un autre thread “sur son chemin”. Un phénomène de résonance se crée et les threads tentent

Attention aux dépendances entre des méthodes synchronisées

Evitez d’utiliser plusieurs méthodes sur un objet partagé

Garder des sections synchronisées courtes

Il faut écrire le code d’arrêt pour se rendre compte des problèmes de locks entre threads

Pour tester du code multithread il faut :
– considérer les faux dysfonctionnements comme des problèmes potentiellement liés au multithread
– commencer par rendre le code normal (sans thread) opérationnel
– faire en sorte que le code multithread soit enfichable (utilisable dans différentes configurations)
– faire en sorte que le code multithread soit réglable (nombre de thread)
– exécuter le code avec plus de threads que de processeurs
– exécuter le code sur différentes plates-formes
– instrumenter (manuellement et/ou automatiquement) le code pour essayer et forcer des échecs