Gem-graph/Concurrent Programming

Concurrent programming for gem-graph

Le thread maître, dans l'ordre:
(1) - cherche, en un temps fini, un espace local dans l'espace global de préemption et, s'il le trouve:
      + tente, en un temps fini, de le préempter et, si la préemption a été possible,
      + crée un thread de calcul en lui communiquant l'adresse de cet espace local
      + et l'inscrit dans la liste des threads)
        
(2) - cherche, en un temps fini, dans la liste des threads s'il y a qui ont fini leur calcul et, s'il y en a:
      + lève la préemption de leur espace local et
      + les retire de la liste des threads.
      
(3) - affiche les résultats.

Chaque thread de calcul, dans l'ordre:
(1) - lit son espace local et les règles écrites dans l'arbre des transitions et les compare.
      (pour faire ce calcul, il n'écrit que dans des variables locales)
      si échec, il se termine, sinon: 
      
(2) - écrit le résultat de son calcul dans l'espace global si une règle peut être appliquée.

(3) - écrit qu'il est terminé dans une liste où le thread maître peut lire et écrire.
      si succès, cette écriture est sa dernière instruction. (après, il est terminé)


>  engine (top-level) boucle infinie:

opération                       type               ressource                      thread maître          thread de calcul
---------                       ----               ----------                     -------------          ----------------
recherche espace local          boucle finie       liste des flèches              lecture
                                                   espace global de préemption    lecture

préemption espace local         section critique   espace global de préemption    fermeture verrou
     vérification               boucle finie       espace global de préemption    lecture
     si confirmation:           boucle finie       espace global de préemption    écriture
                                fin section c.     espace global de préemption    ouverture verrou
si succès préemption:
création d'un thread            section critique   liste des threads              fermeture verrou
                                boucle finie       liste des threads              lecture
si succès,                      assignment         liste des threads              écriture
                                fin section c.     liste des threads              ouverture verrou
                                assignment         mémoire / CPU système          écriture

recherche règle de transition   parcours d'arbre   arbre des transitions                                 lecture
                                                   espace global graphique                               lecture

si succès, transition locale    boucle finie       espace global graphique                               écriture

terminaison d'un thread         section critique   liste des threads                                     fermeture verrou
(adresse connue)                assignment         liste des threads                                     écriture
                                fin section c.     liste des threads                                     ouverture verrou
                                                                                                         fin du thread

levée préemption espace local   section critique   liste des threads              fermeture verrou
                                boucle finie       liste des threads              lecture
si succès,                      assignment         liste des threads              écriture
                                fin section c.     liste des threads              ouverture verrou

thread d'affichage              boucle finie       recherche résultats            lecture
                                                   sorties système                écriture
---------                       ----               ----------                     -------------            ----------------

Trois ressources doivent être accessibles aux threads de calcul de l'automate:
- les transitions (c-a-d: l'arbre des règles) en lecture seulement:
- l'état local (c-a-d: une partie de l'espace global préemptée) pour:
    (1) lire les contraintes nécéssaires pour le choix de la règle de transition
    (2) puis écrire le résultat de son calcul en cas de succès

Le thread n'est crée que si la préemption a été possible
Son calcul aboutit au choix de l'une des règles ou échoue
comme les threads ont seulement besoin de lire l'arbre des règles pendant leur calcul.
Ces lectures ne causent pas de risque de race condition.

L'espace global de préemption et la liste des threads sont 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 :
     + son résultat dans l'espace global (si son calcul a abouti) 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 de préemption et attend pour la liste des threads
- un thread de calcul a acquis la liste des threads et attend pour l'espace global de préemption

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 est coûteuse en temps d'attente.

Le point délicat est qu'il ne faut pas que l'espace global de préemption 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."