Cela dépend de la façon dont les verrous sont mis en œuvre. Si vous le faites comme dans l'article Wikipedia, c'est-à-dire en gardant la section critique avec un booléen par processus¹, vous êtes certainement en difficulté. Si un processus meurt, il ne réinitialise jamais son indicateur, de sorte que l'autre processus boucle pour toujours.
En pratique, vous pouvez protéger votre code contre de nombreuses façons de mourir. Par exemple, prenez cette implémentation de style Java:
flag[1] = true;
turn = 1;
while ( flag[0] == true && turn == 1 ) { Thread.yield(); }
try {
// critical section
}
finally {
flag[1] = false;
}
Cela garantira que l'indicateur est réinitialisé quoi qu'il arrive dans la section critique, tant que le système gère l'erreur. En Java, cela est vrai même pour les débordements de pile et de tas. Donc, à moins que le processus ne disparaisse littéralement ( kill², panne de processeur, déconnexion du réseau, ...), vous êtes en sécurité. Notez que la plupart des logiciels non critiques échouent dans ces cas - comment peut-il gérer une erreur s'il n'est pas en cours d'exécution? - donc cela doit être accepté dans de nombreux cas. Vous pouvez gérer les incohérences au redémarrage si nécessaire.
Si vous utilisez des verrous appropriés au niveau de la langue, le système d'exécution peut gérer les propriétaires de verrouillage disparaissant, c'est-à-dire libérer les verrous avec les propriétaires morts. Vous pouvez simuler cela vous-même en donnant à chaque processus un interrupteur d'homme mort que les autres peuvent lire, ou vérifier directement si le processus de possession de la serrure est toujours actif (si le système le prend en charge).
- De toute façon, cela n'évolue pas bien.
- En Java, je pense que
finalizedevrait s'exécuter même sur kill, mais ce n'est pas garanti par la spécification. kill -9est probablement une condamnation à mort pour toute solution qui nécessite que le processus mourant fasse quelque chose.
