From 86a12cd3b8d5a04818999352518d9b22aea6fad5 Mon Sep 17 00:00:00 2001 From: Jean Sirmai Date: Wed, 7 Apr 2021 18:42:33 +0000 Subject: [PATCH] "The solution in which locks are always acquired in strict order [...] can be mathematically proven to avoid deadlocks [because] you can't get cyclic locking dependencies, which are a necessary condition fordeadlock to occur." --- Concurrent Programming | 59 ++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Concurrent Programming diff --git a/Concurrent Programming b/Concurrent Programming new file mode 100644 index 0000000..c4bcb7a --- /dev/null +++ b/Concurrent Programming @@ -0,0 +1,59 @@ +deux ressources doivent être accessibles aux threads de calcul de l'automate: +- les transitions (c-a-d: l'arbre des règles) + + car chaque thread de calcul doit choisir l'une d'entre elles +- l'état local (c-a-d: une partie de l'espace global préemptée) + + que le thread doit lire pour choisir la règle de transition + + et où il doit écrire le résultat de son calcul en cas de succès + (le thread n'est crée que si cette préemption a été possible) + +puisque les threads lisent seulement l'arbre des règles pendant leur calcul, +et que le seul objet dans lequel ils doivent écrire est l'espace global, +il y n'y a pas de risque de race condition du fait de leurs opérations de calcul. + +le thread maître +(1) - cherche un espace local dans l'espace global et, s'il le trouve, le préempte. +(2) - crée un thread de calcul en lui communiquant l'adresse de cet espace local. +(3) - cherche s'il y a des threads qui ont fini leur calcul et, s'il y en a, +(4) - lève la préemption de leur espace local et les retire de la liste des threads. +les recherches (1) et (3) doivent s'effectuer en un temps fini. + +le thread de calcul +(1) - cherche si une règle peut s'appliquer à son espace local. + (pour faire ce calcul, il n'écrit que dans des variables locales) +(2) - écrit le résultat de son calcul dans l'espace global. +(3) - écrit qu'il est terminé dans une liste où le thread maître peut lire et écrire. + cette écriture est sa dernière instruction. (après, il est terminé) + +L'espace global et la liste des threads sont donc les seuls objets où plusieurs threads doivent écrire: +- le thread maître doit écrire dans les deux au début du calcul (quand il préempte et crée un thread) et +- chaque thread doit écrire dans les deux quand il finit son calcul (si son calcul a abouti) : + + son résultat dans l'espace global et + + son état dans la liste des threads (sinon, le thread maître ne saura pas qu'il peut lever la préemption) + +Des deadlocks sont possibles si: +- le thread maître a acquis l'espace global et attend pour la liste des threads +- un thread de calcul a acquis la liste des threads et attend pour l'espace global + +Mais si les acquisitions se font dans le même ordre pour tous les threads (maître et calcul): +en premier l'espace global et en second la liste des threads, alors il ne peut y avoir de deadlock +car aucun thread ne pourra à verrouiller la liste des threads tant qu'il n'a pas eu accès à l'espace global. + +Une première solution est donc de ne réaliser que simultanément l'ensemble des opérations +sur l'espace global et la liste des threads (en début comme en fin de calcul) +et de ne les réaliser que lorsque les deux ressources ont été acquises +par le thread maître en début de calcul ou par le thread de calcul lorsqu'il a fini. +Cette solution peut être coûteuse en temps d'attente. + +Le point délicat est qu'il ne faut pas que l'espace global soit modifié entre: +- le moment où le thread maître vient de trouver un espace local convenable et +- le moment où il a fini de préempter cet espace local. + +Il ne semble pas y avoir de risque entre: +- le moment où un thread de calcul a fini de modifier son espace local, et +- le moment où le thread maître lève la préemption associée + +La préemption et sa levée doivent être des opérations atomiques + +David Beazley & Brian K.Jones Python Cookbook 2013 p503: +"The solution in which locks are always acquired in strict order [...] can be mathematically proven to avoid deadlocks [because] you can't get cyclic locking dependencies, which are a necessary condition fordeadlock to occur." +