Dans une application, deux tâches peuvent consulter ou modifier la même donnée presque au même instant. Sans coordination, leurs opérations se chevauchent et produisent des résultats imprévisibles : c’est une condition de course, même si chaque tâche semble correcte lorsqu’elle fonctionne seule.
Les verrous protègent ces accès, mais leur usage introduit d’autres risques : interblocage, famine ou attente active. Comprendre ces mécanismes aide à choisir une synchronisation adaptée plutôt qu’à multiplier les protections sans examiner leurs effets.
A retenir :
- Accès partagés protégés par une exclusion mutuelle cohérente
- Ordre d’acquisition stable pour limiter les interblocages
- Attentes courtes et stratégies équitables contre la famine
- Primitives adaptées à la durée et au type de partage
Verrous et condition de course : protéger la section critique
Lorsqu’une donnée est partagée, la première priorité consiste à empêcher des modifications simultanées incompatibles. Cette protection concerne la section critique, c’est-à-dire la portion du programme qui accède à la ressource commune.
Perte de mise à jour et exclusion mutuelle
Un compteur illustre simplement le problème : deux threads lisent la même valeur, ajoutent chacun une unité, puis écrivent leur résultat. L’une des modifications peut écraser l’autre, si bien que deux incréments ne produisent parfois qu’une seule hausse.
En Rust, une variable globale modifiable déclarée avec unsafe contourne les garanties habituelles du langage. Des opérations comme COMPTEUR += 1 ne deviennent pas atomiques pour autant ; une telle course sur une donnée non atomique constitue un comportement indéfini.
Un mutex impose l’exclusion mutuelle : un seul thread détient le verrou à la fois. Selon les primitives de synchronisation employées, un sémaphore peut aussi limiter le nombre d’accès simultanés, tandis qu’un moniteur associe données partagées et opérations coordonnées.
La protection doit couvrir toute l’opération logique, pas uniquement une lecture ou une écriture isolée. Sinon, le programme peut encore observer un état intermédiaire ou laisser passer une mise à jour concurrente.
Les différences entre ces mécanismes deviennent plus visibles lorsqu’on compare leurs garanties et leurs risques pratiques.
Repères de synchronisation :
- Mutex : un seul détenteur autorisé dans la section critique
- Sémaphore : accès limité à un nombre défini de tâches
- Moniteur : données et opérations réunies dans une abstraction coordonnée
- Opération atomique : modification indivisible pour une donnée compatible
| Mécanisme | Usage courant | Point de vigilance |
|---|---|---|
| Mutex | Protéger une ressource exclusive | Libération garantie, même en cas d’erreur |
| Sémaphore | Contrôler plusieurs accès disponibles | Respecter le nombre d’acquisitions et de libérations |
| Moniteur | Encapsuler état partagé et coordination | Éviter les appels bloquants mal ordonnés |
| Opération atomique | Modifier simplement une valeur partagée | Ne remplace pas une coordination complexe |
Interblocage et verrouillage : éviter l’attente circulaire
Protéger une ressource ne suffit pas si plusieurs threads peuvent se bloquer mutuellement. L’interblocage apparaît notamment lorsque chacun détient un verrou attendu par l’autre.
Ordre des verrous et dépendances circulaires
Imaginons deux threads et deux mutex : le premier prend le verrou A puis demande B, tandis que le second prend B puis demande A. Si chacun conserve son premier verrou, aucun ne peut poursuivre et le programme reste bloqué.
Ce scénario dépend de l’ordonnancement : une courte pause peut rendre la situation plus facile à observer, mais elle ne constitue pas une condition nécessaire. Le remède classique consiste à imposer partout le même ordre d’acquisition, par exemple A avant B.
On peut aussi réduire la durée de détention des verrous ou regrouper l’accès dans une fonction qui acquiert les ressources de manière cohérente. Ces choix diminuent les dépendances, sans garantir à eux seuls une équité parfaite entre threads.
Prévention des blocages :
- Ordre global identique pour chaque acquisition multiple
- Sections critiques courtes et opérations bloquantes limitées
- Gestion explicite des erreurs pendant l’acquisition
- Évaluation des dépendances entre ressources partagées
Un interblocage immobilise plusieurs tâches ; une attente active peut, elle, consommer le processeur sans faire progresser le travail.
Attente active, famine et inversion de priorité
Une boucle qui répète une tentative atomique sans pause réalise une attente active. Si le verrou n’est jamais libéré, le thread continue à vérifier son état et gaspille du temps processeur au lieu de dormir.
La famine décrit une autre situation : une tâche reste privée d’accès pendant que d’autres progressent. Une boucle utilisant try_lock peut illustrer ce risque si un thread concurrent reprend constamment le verrou, mais le résultat dépend de l’ordonnanceur et n’est pas garanti par cet exemple seul.
L’inversion de priorité survient lorsqu’une tâche prioritaire attend une ressource détenue par une tâche moins prioritaire, parfois retardée par des tâches intermédiaires. Des politiques d’héritage de priorité peuvent atténuer ce phénomène dans les systèmes qui les prennent en charge.
Choisir une synchronisation adaptée aux accès concurrents
Après avoir identifié les blocages possibles, il faut choisir une stratégie proportionnée au partage réel. Une ressource peu disputée ne demande pas nécessairement le même mécanisme qu’un état complexe modifié par de nombreux threads.
Mutex, atomiques et stratégies de progression
Un mutex convient lorsque plusieurs opérations doivent rester cohérentes ensemble, comme vérifier un solde puis le modifier. Une opération atomique est souvent plus simple pour un compteur isolé, mais elle ne protège pas automatiquement plusieurs variables liées.
Dans l’exemple du compteur, remplacer la variable partagée non protégée par un type atomique adapté évite la mise à jour perdue. Si la logique comprend plusieurs étapes, un mutex ou un moniteur rend généralement l’intention plus lisible.
Le choix dépend aussi de la progression attendue : certains verrous endorment les threads en attente, tandis qu’un verrou tournant peut être utile seulement pour des attentes très brèves et maîtrisées. Une politique équitable aide à réduire la famine, au prix parfois d’un coût supplémentaire.
Critères de choix :
- Compteur indépendant : opération atomique adaptée au type
- État composé : mutex protégeant l’ensemble de l’opération
- Ressource disponible en plusieurs exemplaires : sémaphore
- Attente prolongée : mécanisme évitant une boucle active
Vérifier le comportement plutôt que supposer l’équité
Les résultats observés pendant un test ne prouvent pas que le programme est sûr sous toutes les charges. Les courses et blocages dépendent souvent du calendrier d’exécution, qui varie selon la machine et l’activité concurrente.
Pour diagnostiquer, les équipes peuvent examiner les sections critiques, cartographier l’ordre des verrous et tester des charges qui multiplient les accès simultanés. Elles doivent aussi vérifier les chemins d’erreur, car une sortie prématurée peut empêcher la libération attendue.
Un système robuste combine des protections simples, un ordre documenté et des tests ciblés. Cette discipline rend les problèmes plus prévisibles avant qu’ils ne se manifestent sous la charge réelle.
| Symptôme observé | Cause possible | Piste de vérification |
|---|---|---|
| Valeur finale incohérente | Condition de course | Examiner les lectures et écritures partagées |
| Plusieurs tâches bloquées | Interblocage | Comparer l’ordre d’acquisition des verrous |
| Processeur occupé sans progrès | Attente active | Contrôler les boucles de nouvelle tentative |
| Une tâche attend indéfiniment | Famine ou priorité défavorable | Évaluer l’équité et l’ordonnancement |
Un mot qui se comprend dossier après dossier
Qu'il s'agisse de philosophie bouddhiste, de méditation, de culture tibétaine, d'industrie durable, de linguistique ou de bien-être, chaque rubrique raconte une facette différente de la même question : comment un même mot peut porter, à la fois, une pensée millénaire et un usage bien actuel. Rien n'est figé : chaque contexte nouveau peut encore faire évoluer ce sens.
Pour aller plus loin
- Comparer plusieurs sources avant de juger la portée d'une traduction ou d'une définition
- Replacer chaque terme dans son contexte culturel réel, pas seulement sa traduction littérale
- S'intéresser aux usages vivants de la langue autant qu'aux définitions figées
- Observer comment un même mot évolue d'un domaine à l'autre au fil du temps
