62 lines
3.6 KiB
Plaintext
62 lines
3.6 KiB
Plaintext
Concurrent programming for gem-graph
|
|
|
|
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."
|
|
|