/* Page prose (fr) */
"Overview" = "# Les dangers de la concurrence\n\nTu as sorti du travail du thread principal avec des files, attendu des lots avec des Dispatch Groups, et rationné l'accès avec des sémaphores. Maintenant, les arêtes vives. Au moment où deux morceaux de travail touchent la *même* valeur en même temps, une nouvelle classe de bug apparait: un bug qui passe tous les tests sur ta machine, part en production, puis corrompt un nombre pour un utilisateur sur mille. Imagine une banque à guichets: un seul solde partagé, une rangée de caissiers, tout le monde plongeant la main dans le tiroir à la fois. Ce chapitre parle de ce qui tourne mal quand ils ne se coordonnent pas, et des outils classiques qui les rendent sûrs.\n\n---\n\n## Ce que tu vas apprendre\n\n* Ce que sont une **condition de course** et une **data race**, et comment en repérer une en lisant du code.\n* Pourquoi les courses sont **non déterministes** (correctes la plupart des exécutions, fausses sur certaines) et donc si brutalement difficiles à reproduire.\n* Deux corrections classiques: canaliser les écritures à travers une **file en série**, ou utiliser une **file concurrente avec une `.barrier`** (le patron lecteurs-écrivains).\n* Ce qu'est un **interblocage**, et l'erreur d'une seule ligne qui gèle une app pour toujours.\n* Ce qu'est l'**inversion de priorité**, en termes simples.\n* Une liste de vérification pour raisonner sur la sûreté vis-à-vis des threads sans rien exécuter.\n\nQuand tu es prêt, passe à la page suivante et nous casserons exprès le solde partagé d'une banque.\n\npage 1 sur 9  |  [Suivant: La data race](@next)";
