\section{Les deadlocks}
Les deadlocks se produisent lorsque qu'un thread essaye de s'attendre lui même directement ou par l'intermédiaire de d'autre threads. Il est donc nécessaire  de savoir quel thread est effectivement attendu lors d'un join.


Lorsque qu'un thread est attendu, on stocke dans le champ \code{retvalue} le pointeur vers le thread qui attend. C'est notamment utile pour remettre le thread qui attend dans la fifo principal pour qu'il soit réordonnancé. Mais on peut également l'utiliser, et c'était notre première idée, pour itérer sur la liste des threads qui s'attendent entre eux et récupérer le "dernier thread" attendu afin de s'assurer qu'il ne s'agit pas de celui qui essaye de join.

Cependant cette technique, bien que simple, n'est pas optimisée et est de complexité linéaire par rapport au nombre de thread qui s'attendent entre eux. On peut notamment voir ce manque de performance dans le test \code{22-create-many-recursive}.

Pour résoudre ça, on rajoute un champ vers un pointeur d'une nouvelle structure \code{last\_thread\_t} dans notre structure \code{thread\_entry\_t} qui va permettre de designer le dernier thread qui est attendu. 
Pour récapituler, chaque thread attendu possède une référence vers une structure qui elle pointe vers le dernier thread attendu du groupe. Ainsi la mise à jour et la consultation du dernier thread attendu lors d'un join se fait en temps constant. On peut voir cette structure comme un pointeur d'un pointeur de \code{last\_thread\_t} mais il a été choisi d'introduire une structure pour garder le nombre de références vers cette structure pour pouvoir la free lorsque qu'elle n'est plus utilisée.

\begin{figure}[h]
    \centering
    \includesvg[width=\linewidth]{img/graphs/22-create-many-recursive-deadlock.svg}
    \caption{Comparaison version itérative et version optimisée}
    \label{fig:deadlock-comparaison}
\end{figure}

La figure \ref{fig:deadlock-comparaison} nous montre le très net bénéfice de faire intervenir une structure annexe pour consulter le dernier thread attendu. L'écart entre les deux méthodes est aussi prononcé que la différence de performance entre nos threads et ceux de Brieuc.