tcqpad / people-fsp Goto Github PK

On veut générer un environnement pour la simulation en parsant le fichier d'une carte enregistrée #3 .

On doit pouvoir générer les personnes aux bonnes coordonnées et de même pour les obstacles.

Afin d'avoir des mesures plus précises, et représentatives de l'exécution du programme, lorsque l'option -m est fournie en paramètre d'exécution #4, l'application est lancée 5 fois, et la mesure finale est la moyenne des 3 valeurs intermédiaires.

Pour que les mesures soient cohérentes, la simulation lancée 5 fois doit être identique à chaque nouveau lancement. Pour cela, la tâche #3 doit être complétée avant de réaliser celle-ci #7.

Afin de garantir que tous les threads tournent en même temps lors de la simulation des 2 scénarios #1, une Barrière devrait être mise en place pour que tous les threads attendent leurs collègues le temps que l'appel à start() soit fait pour chacuns d'eux, puis qu'ils puissent démarrer la simulation à l'exact même moment.

Les personnes traversent les obstacles => les obstacles ne sont pas reconnus comme tel

People are hanging up on exit and threads are running indefintely due to the exit of the map not recognized anymore, j.e., the method of the map: isAtExit().

Afin de pouvoir calculer la moyenne de la consommation CPU et du temps de response demandé en #7, il est nécessaire de sauvegarder les résultats dans un fichier à chaque fin d'exécution (afin de libérer de la mémoire RAM).

La sauvegarde sera au format JSON avec un JSONArray de la forme :

[
  {
    "run_0": {
      "cpu_usage": "[0.0, 17.6, 19.3, 30.6, 22.8, 35.6, 28.0, 21.4, 26.5, 12.7, 26.5]",
      "res_time": 1.13100004196167
    }
  }
.....
]

Avec les threads de #6 , on doit pouvoir gérer le déplacement des personnes d'une zone à une autre (entre autre).

Problème : nous avons une zone critique à l'interface de chaque zones

Pour cela, on va mettre un verrou sur chaque case aux frontières de ces zones

Afin de choisir et exécuter un des scénarios demandés (t0/t1), l'algorithme devrait être refactor afin de déléguer la responsabilité de chacun des scénarios à des classes différentes.

Après avoir parser le fichier map.txt, les Persons sont mal chargés. Ca provoque une sorte de NullPointerException

#5

Quand les obstacles se génèrent sur la carte, ceux s'y peuvent se superposer et donc, bloquer le déplacement des gens.

Afin d'écrire un algorithme efficace et parallèle, le verrouillage de la map ne doit pas être fait à gros grain comme c'est le cas à l'heure actuelle.

Au contraire, il serait plus rapide de donner un verrou par case de la carte, et de réaliser la synchronisation des threads à grain fin, pour chaque case de la map.

Ceci permettrait de réduire le goulot d'étranglement dû à la synchronisation, et d'accélérer considérablement la vitesse d'exécution du programme.

Cette tâche est associée à la tâche de refactor #9, puisqu'elle permet une amélioration de la vitesse d'exécution du programme.

Pour le scénario 2, on veut partager la carte en 4 parts équitables et attribuer cette portion de carte à un Thread.

Dans le scénario 2, l'algorithme actuel de la simulation est buggé.
Il semble que les zones de la map MapZone terminent leur exécution lorsque leur liste de personnes est vide.

Afin de relancer 5 fois une simulation identique pour le scénario 2, il est nécessaire de pouvoir charger la carte sauvegardée lors de la première des 5 simulations.

Afin de pouvoir choisir quel scénario utiliser (t0 ou t1), une option de lancement doit être mise en place afin de pouvoir choisir :

• t0
• t1
• t0 & t1

Une option de lancement -m doit être ajoutée aux options de lancement du programme, afin de lancer la fonctionnalité "mesurer la consommation CPU".

De plus, notre programme doit, pendant la simulation, pouvoir récupérer la consommation du CPU de l'utilisateur, et renvoyer cet ensemble de données une fois la simulation finie.

There's a bug where people are spawning on an obstacle. This may lead to the bug in #11 and makes the algorithm run forever since people in an obstacle are unable to move.

Lorsqu'on génère une carte, on ne peut l'utiliser que pour une seule simulation. On ne peut donc pas comparer les deux scénarios dans le même environnement.

On doit pouvoir enregistrer une carte avec ce format :

• "#" => bordure, obstacle
• " " => espace vide
• "X" => une personne
• "O" => la sortie

Actuellement, la visualisation de la simulation est trop lente. On doit pouvoir l'accélérer en utilisant une technologie autre que Turtle.

Afin de relancer 5 fois une simulation identique pour le scénario 2, il est nécessaire de pouvoir sauvegarder la carte générée à la première des 5 simulations.

There's a bug after the refactor in #10 making the hasPerson(person) function in the Tile class returning false even if the current Tile has a person on it.

This bug makes the algorithm hang up and run indefinetely whenever it occurs. I think it's happening when people are spawning in an obstacle.