# :computer: PCO Laboratoire 07 : ConcurrencyAnalyzer

Auteurs : Gomes Christian, Werkle Johann

Date : 20.06.21

[TOC]

## :blue_book: Introduction

Ce présent document a pour but la présentation de notre travail concernant le laboratoire 07 de PCO intitulé "ConcurrencyAnalyzer". Ce laboratoire consiste en l'implémentation de méthodes de contrôle et d'instrumentalisation de code à caractère concurrent.

## :book: Conception

La prise en main du laboratoire a débuté avec une étude assidue du travail demandé et du contexte d'exécution des outils qui nous étaient demandés d'implémenter. Ces outils concernent trois méthodes de la classe `ConcurrencyAnalyzerMesa`:

| Méthode | Description |
| ------------------------------------------------------------ | ------------------------------------------------------------ |
| `void start()` | Méthode exécutée à l'initialisation d'un nouveau scenario. Nous l'utilisons pour évaluer la longueur du scénario à venir. |
| `void startSection(ObservableThread *thread, int sectionNumber)` | Méthode exécutée pour la création des nouvelles section. |
| `void endSection(ObservableThread *thread)` | Méthode exécutée pour arrêter une section courante. |
| `void endScenario(ObservableThread *thread)` | Méthode exécutée pour arrêter un scénario. |
| ` void checkedBlocked(int /*nbBlocked*/)` | Méthode appelée lorsqu'un cas d'interblocage est en cours sur une sémaphore. |
| `bool aborted()` | Méthode appelée après un interblocage pour signaler si un interblocage a été détecté. |

### Réflexion - Partie 1

Dans cette étape , on s'intéresse à des scénarios linéaires sans blocage. On a implémenté `startSection`, `endSection` et `endScenario` à l'aide d'un moniteur de Mesa.

Un thread devra attendre si la section qu'il souhaite commencé ne correspond pas à celle à suivre pour scénario ou si l'id du thread ne correspond pas aussi.

Dans le cas où le thread en question réussi son étape du scénario, il notifiera alors tous ceux en attente pour revalider la prochaine étape de la séquence car le thread pourrait déjà avoir été mis en attente.

Chaque fin de scénario mettra son statut en `EndAllScenario`

### Réflexion - Partie 2

On s'intéresse ici à des scénarios linéaires sans blocage avec atteinte de la profondeur maximale.

Nous voulons mettre en place un mécanisme qui permet d'arrêter l'analyse lors tous les scénarios de tests ont été effectué.

Pour résoudre ce problème, nous avons implémenté une fonction `isScenarioOver` où l'idée est de vérifier que l'étape courante du scénario est toujours valable par rapport à sa profondeur maximale.

Dans les cas où le problème se produirait, on met le statut à `Depth`

### Réflexion - Partie 3

Cette étape consiste à gérer les interblocages des primitives de synchronisation.

Pour cela, il est nécessaire de compléter la fonction `CheckedBlocked` afin de pouvoir réagir lorsque le programme nous signale que des threads bloquent sur un sémaphore (deadlocks).

Le but en somme est de pouvoir terminer les threads bloqués en prenant en compte leur non-exécution dans l'analyse du scénario.

Nous pensons que la résolution n'est pas aboutie compte tenu du fait que certains tests prennent en compte également la partie 4, comprenant les deadend, ce que nous ne détectons pas de manière efficace.

### Réflexion - Partie 4

La partie 4 concernant la mise en place des DeadEnd, nous avons eu quelques difficultés dans sa résolution.

Nous avons mis en place un système pour connaître le nombre de threads en attente afin de nous en servir dans le contrôle des DeadEnd mais n'avons pas su de quelle manière les identifier en plus du fait que certains tests provoquaient également des deadlocks.

## :bookmark_tabs: Tests effectués

Outre les vérifications d'usage à l'aide de tests empiriques effectués au fur et à mesure du développement, nous avions un certain nombre de tests à disposition pour évaluer le fonctionnement de nos méthodes. Les tests en question et nos observations vis-à-vis de l'exécution de ces derniers sont consignés dans le tableau ci-dessous :

| Nb | Test | Résultat | Commentaire | :+1: or :-1: |
| ---- | ------------------------ | -------------------------- | ------------------------------------------------------------ | ------------ |
| 1 | `CaTestNumber` | `End : AllScenario : 1680` | Ce test se rapporte à l'étape 1. Il ne nous a pas posé de problème particulier outre une certaine incompréhension sur la nécessité d'appeler la méthode `endSection` au terme du `startSection` (ce qui n'était par très clairement précisé dans le cahier des charges) | :+1: |
| 2 | `CaTestNumberDepth` | `End : Depth : 1680` | Ce test valide le travail effectué pour l'étape 2. Il consiste à vérifier que nous sommes capable de prendre en compte la profondeur d'un scénario et de vérifier que l'on effectue pas plus de sections que nécessaire. | :+1: |
| 3 | `CaTestBlock` | Erreur à l'exécution | Ce test se rapporte aux étapes 3 (et 4...). Il vérifie que notre implémentation gère correctement les cas d'interblocage et de | :-1: |
| 4 | `CaTestNumberDeadEnd` | Erreur à l'exécution | Ce test est destiné à la validation de l'étape 4, visant à vérifier si les threads observés sont susceptibles de provoquer un scénario impossible. | :-1: |
| 5 | `CaTestBridgeSimple1` | Erreur à l'exécution | Ce test vise à vérifier que l'implémentation complète du programme gère toujours correctement la terminaison d'une section en `End : AllScenario`. | :-1: |
| 6 | `CaTestBridgeSimple2` | Erreur à l'exécution | Idem que le test `CaTestBridgeSimple1`. | :-1: |
| 8 | `CaTestNumberEndSection` | `End : AllScenario : 1680` | Ce test se rapporte également à l'étape 1. Il permet de vérifier que le code gère correctement les appels à la méthode `endSection`. | :+1: |
| 9 | `CaTestBlockSingle` | `End : Deadlock : 1000` | Ce test est destiné à la validation de l'étape 3. Il ne lance qu'un seul scénario qui bloque trois threads sur un sémaphore. | :+1: |

## :end: Conclusion

Ce laboratoire, bien qu'intéressant en soi, s'est révélé être considérablement frustrant.

Difficile et assez nébuleux dans sa donnée, nous y avons passé un temps très conséquent à une période de l'année où le temps manque cruellement et que les rendus à effectuer affluent.

Cela ne serait pas tant un problème car la situation est toujours la même pour cette période mais ce laboratoire ne nous apporte que peu de nouvelle matière par rapport au dernier laboratoire pour un investissement frôlant l'absurde compte tenu du fait que nous y avons consacré nettement plus de temps que le temps alloué chaque semaine, le tout pour un résultat médiocre.

En somme, notre ressenti concernant ce laboratoire est qu'il était de trop, autant en terme d'investissement qu'en terme de bénéfices.