Sujet : concurrency
-
Annulation et délais en Go avec context.Context
Faire transiter un context.Context depuis la requête entrante à travers chaque appel susceptible de bloquer, dériver des contextes enfants avec WithTimeout ou WithCancel, toujours appeler la fonction d'annulation, et vérifier ctx.Done() dans les boucles afin qu'une déconnexion du client ou un délai dépassé arrête tout l'arbre de goroutines au lieu de les laisser s'exécuter.
-
Quand asyncio aide, et quand ce n'est pas le cas
asyncio exécute de nombreuses tâches limitées par les entrées-sorties (I/O) sur un seul thread en se suspendant aux points await ; il n'accélère pas le code limité par le calcul (CPU), et les appels bloquants à l'intérieur des coroutines bloquent toute la boucle.
-
Les niveaux d'isolation des transactions en pratique
Read committed, repeatable read et serializable échangent de la concurrence contre de la cohérence ; savoir quelles anomalies chaque niveau autorise permet de décider quand ajouter des verrous explicites ou des nouvelles tentatives.
-
Choisir entre threads, processus et asyncio pour une charge de travail Python
Classer d'abord le chemin critique : l'attente d'E/S convient à asyncio (nombreuses connexions, bibliothèques asynchrones) ou à un pool de threads (peu d'appels bloquants) ; le calcul Python pur nécessite des processus ou une build sans GIL (free-threaded). Le code natif qui libère le GIL peut utiliser des threads. Borner chaque pool, choisir explicitement la méthode de démarrage des processus et écrire le chemin d'arrêt.
-
Vérifier la lecture après écriture à l'aide des révisions renvoyées
Confirmer une écriture au moyen de son identifiant stable et de sa révision, sans confondre une mise à jour concurrente plus récente avec le contenu exact soumis.
-
Traiter les jetons d'écriture périmés comme des signaux de relecture
Se remettre d'un échec de précondition d'écriture en relisant et en reconstruisant le changement voulu par rapport à la version actuelle.
-
Empêcher l'exécution concurrente d'un script d'administration : flock, lockf et mutex nommé sous Windows
Un script d'administration planifié ou déclenché par un agent, qui peut être relancé avant la fin de l'exécution précédente, exige un verrou et non l'espoir que cela n'arrive pas. flock(1) sous Linux et lockf(1) sous FreeBSD lient un verrou consultatif du noyau à un processus en cours, de sorte qu'il ne devient pas obsolète comme un fichier PID oublié ; sous Windows, un System.Threading.Mutex nommé joue le même rôle.
-
À partir de quelle charge la version free-threaded de CPython surpasse-t-elle un pool de processus pour un service mêlant E/S et calcul CPU ?
Question ouverte : la version free-threaded supprime le GIL mais ajoute une surcharge en mode mono-thread et peut retomber sur le GIL lorsqu'une extension non préparée est importée, tandis que les pools de processus paient le coût du pickling et de la duplication mémoire ; pour quels rapports temps CPU / temps d'attente, quelles tailles d'ensemble de travail et quels nombres de cœurs un pool de threads sur la version free-threaded offre-t-il un meilleur débit par cœur ?
-
Pièges d'async/await en C# : sync-over-async, async void et ConfigureAwait
Les erreurs classiques du code asynchrone en C# consistent à bloquer sur une Task avec .Result, .Wait() ou GetAwaiter().GetResult() (blocages sous un SynchronizationContext monothread, famine du thread pool sur les serveurs), à écrire des méthodes async void dont les exceptions ne peuvent pas être interceptées, et à mal placer ConfigureAwait(false), qui a sa place dans les bibliothèques génériques et non dans le code applicatif.
-
Les threads virtuels de Java en résumé : ce qui change et ce qui ne change pas
La JEP 444 (JDK 21) ajoute les threads virtuels : des threads bon marché ordonnancés par le JDK sur un petit pool de threads de plateforme porteurs (carriers), qui se démontent lorsqu'ils bloquent sur la plupart des E/S du JDK, de sorte que le code à un thread par requête passe à l'échelle sans style asynchrone. Ils ne sont pas plus rapides, ne doivent jamais être mis en pool, et jusqu'à la JEP 491 (JDK 24), bloquer à l'intérieur d'un synchronized épinglait (pinned) le thread porteur.
-
Utiliser des baux (leases) expirants pour les tâches distribuées
Protéger une tâche récupérée contre un ancien worker retardé grâce à des vérifications de propriété et à un jeton de barrage (fencing token) strictement croissant.
-
Le GIL : ce qu'il sérialise et ce qu'il ne rend pas sûr
Le verrou global de l'interpréteur ne laisse qu'un seul thread exécuter du bytecode Python à la fois et protège les structures propres à l'interpréteur, pas les invariants du programme : des séquences de lecture-modification-écriture telles que counter += 1 ou une vérification puis affectation sur un dict nécessitent toujours un threading.Lock. Les builds sans GIL conservent la même règle.
-
Goroutines, channels et le paquet sync : la concurrence en Go en bref
Une instruction go exécute un appel de fonction de façon concurrente sur une pile légère et extensible ; les channels transmettent des valeurs entre goroutines et bloquent jusqu'à ce que les deux parties soient prêtes ; sync.WaitGroup, Mutex et Once couvrent les cas où le partage de mémoire est plus simple. Une course de données (data race) est un bug dont le résultat n'est que partiellement contraint par le modèle mémoire, et le détecteur -race est l'outil pour la trouver.
-
Revalider l'état après une décision de Jev et avant un effet de bord
Empêcher qu'une décision portant sur un état applicatif antérieur soit appliquée aveuglément après que l'enregistrement concerné, les permissions ou la politique ont changé.
-
Couverture du détecteur de course Go : une exécution propre ne dit rien des chemins non exécutés
Rattacher les résultats de go test -race aux chemins concurrents réellement exercés, y compris le démarrage et l'arrêt.
-
Erreurs Send de Tokio : examiner l'état conservé à travers un await
Corriger un futur (future) lancé en examinant ce qui survit à la suspension, plutôt qu'en ajoutant des implémentations de trait non sûres (unsafe).
-
Borner la concurrence par hôte et par compte
Contrôler les appels d'outils simultanés séparément du débit de requêtes, avec des files d'attente bornées et une libération de permis sûre face à l'annulation.
-
Triage ThreadSanitizer : reconstituer le contrat de synchronisation manquant
Lire les deux chemins d'accès en conflit et réparer la règle de propriété ou de synchronisation qui les relie.
Lisible par machine : JSON