Worldedit

Ayane · Posté le: 24/05/11 08:56 Sujet du message: Threads

Je cherche actuellement des informations sur la gestion des threads au niveau des déclencheurs.
Je sais que Wc3 est encore capable d'exécuter du code Jass en parallèle car cela m'est arrivé sur la carte La Course d'Ayane où j'ai dut agencer les déclencheurs différemment. Récemment j'ai cherché à créer des threads afin d'effectuer un traitement de manière parallèle, mais cela a l'air de s'exécuter plutôt de manière sériale, peut être parce que j'appelais certaines fonctions qui exécutaient un verrou (lecture d'une hashtable pour le passage de paramètres).
J'aimerais donc savoir s'il y a des personnes qui disposent d'informations à ce sujet dans le but de pouvoir l'exploiter pour du traitement parallèle.
_________________

Troll-Brain · Posté le: 24/05/11 15:15 Sujet du message:

A ce que je sache dans warcraft il n'est pas possible de lancer plusieurs thread en parallèlle, tout se fait en série.

Les moyens d'ouvrir un nouveau thread (et de mettre en pause le thread précédent) du plus rapide au plus lent :

- ForForce
- TriggerEvaluate
- TriggerExecute / ExecuteFunc

Et aussi les GroupEnum il me semble.
_________________

Le violet, c'est moche.

Ayane · Posté le: 24/05/11 18:02 Sujet du message:

TriggerEvaluate est plus rapide que TriggerExecute alors qu'il doit en plus vérifier les conditions?
Ainsi si un déclencheur A est en cours d'exécution et qu'un déclencheur B s'exécute entre temps, le déclencheur A se met en pause, exécute B, puis reprend l'exécution de A?
Si c'est le cas le seul avantage que j'ai eu à coder mes traitements pouvant fonctionner en parallèle a été d'éviter la barrière du temps d'exécution d'un déclencheur.
_________________

Troll-Brain · Posté le: 24/05/11 18:45 Sujet du message:

Ayane · Posté le: 24/05/11 20:16 Sujet du message:

Pour le fait de coder dans les conditions j'étais au courant, en fait dans les actions l'exécution est plus complexe comme par exemple le fait qu'il puisse être arrêté pour être repris plus tard. Cela doit créer une instance d'un thread WC3 alors que dans les conditions il exécute le code directement, ce qui implique qu'il ne doit pas pouvoir être mis en pause en codant ainsi. Coder dans les conditions n'est donc pas du tout fait pour ce que je recherche.

Pour le rendu je n'ais qu'un seul déclencheur périodique de 40ms, j'y ais déplacé tous mes codes périodiques en y mettant des pseudo-timers, c'est à dire une variable entière que je décrémente à chaque itération, lorsqu'elle atteind 0 j'exécute le code et je réinitialise la variable. Au début j'avais fait plusieurs déclencheurs mais il arrivait que l'un s'exécute pendant l'exécution de l'autre, tout mettre dans un seul m'a donc permis de régler ce conflit de threads.
_________________

Troll-Brain · Posté le: 24/05/11 20:23 Sujet du message:

Ayane · Posté le: 25/05/11 08:21 Sujet du message:

Ce n'est pas étrange si l'on considère que le déclencheur B a mis en pause le déclencheur A.
Pour le refaire il suffit juste de légèrement modifier ma carte. J'ai eu le problème en fait à deux endroits:
- Le premier consiste en des déclencheurs de lancement, l'une des série d'exécution était ceux de la cinématique donc à la base un déclencheur avec Time Elapsed 0.0 puis un Run sur Scene1 Send Cinematic Text avec l'option Attendre et un Run sur Scene2 qui lui créé deux unités qui sont enregistrées dans le système de physique. La seconde série d'exécution était un déclencheur avec Time Elapsed de 10.65 sec environ, il coïncidait avec le lancement de Scene2 et se charge de lancer la course, donc il fait un Run sur VEH Create qui lui créé les véhicules qu'il ajoute au système physique.
Là où je me suis rendu compte qu'il y avait un problème de thread c'est que normalement les véhicules ont une masse de 100 et les paysans ont une masse de 1 ce qui fait que lorsqu'on les percute on ne le sent pratiquement pas; mais avec cette disposition il arrivait des fois (en relançant la carte cela pouvait être normal) que l'on percute les paysans comme sur un mur, c'est à dire qu'ils avaient une masse assez importante. La seule possibilité étant que la création de véhicule puisse s'exécuter pendant la création des paysans. C'est donc le déclencheur de la Scene2 qui lance les déclencheurs d'initialisation de la course ce qui a réglé le problème.
- Le deuxième était la vérification qu'une unité se trouve dans la lave, toutes les 500ms cela vérifiait si l'unité se trouvait dans la lave et si c'est le cas cela déplaçait l'unité à un checkpoint et réinitialisait plusieurs valeurs, notamment pour mettre à zéro la vélocité du véhicule. Cela annulait également les touches appuyées, variables elles manipuler également par la gestion de l'ordinateur qui s'exécutait également dans un autre périodique (toutes les 250ms). C'était moins visible puisque corrigé par la suite, mais il arrivait que le véhicule une fois téléporté conserve certaines caractéristiques de la trajectoire précédemment calculée, l'ordinateur pouvait donc commencer à partir dans le sens opposé comme si la téléportation n'avait pas annulée ses précédentes données (puis évidemment il corrigeait après sa trajectoire pour suivre le trajet qu'il faut). J'ai donc mis le périodique de l'IA et de la lave dans celui du rendu physique avec des pseudo-timers et cela a résolu tous les problèmes de ce genre qui avait été rencontrés.

Conclusion: les threads de WC3 ne s'exécutent pas forcément parallèlement, en considérant qu'un thread peut être mis en pause pendant son exécution pour laisser l'exécution à un autre thread cela explique tout à fait les phénomènes observés. C'est fort possible étant donné que lors de la sortie de WC3 il n'y avait que très peu de PC multi-CPU (sans parler des systèmes d'exploitations qui ne le gérait pas); sur mono-CPU on considérait que c'était cela le fonctionnement d'un processus: on en exécute une partie puis on le met en pause en sauvegardant les registres et on passe à l'exécution d'un autre processus en chargeant les données correspondant dans les registres. On n'avait pas la même conception de traitement parallèle car ce n'était pas possible à l'époque, il ne s'agissait que d'une émulation qui pouvait faciliter l'algorithme. Il aurait fallut que Blizzard utilise des threads système au lieu de threads software, les systèmes d'exploitations de maintenant aurait permis au Jass de faire du traitement parallèle.
_________________