Synchronisation en C# : lock, Monitor, Interlocked

En C#, la synchronisation s’appuie sur lock, Monitor (Enter/Exit/Wait/Pulse) et Interlocked. Voici comment les choisir et les utiliser correctement.

lock : sucre syntaxique de Monitor

lock compile vers Monitor.Enter/Exit et est réentrant par thread. À privilégier par défaut.

Éviter de locker des objets publics, des types string ou Type; préférer un champ privé readonly dédié.

Monitor.Enter/TryEnter/Exit : contrôle fin + Wait/Pulse

Monitor.TryEnter avec timeout permet de limiter le risque de deadlock et d’appliquer un plan B.

Condition variables: Monitor.Wait libère le lock et se met en attente d’un Pulse/PulseAll. Toujours vérifier la condition dans une boucle.

Interlocked : opérations atomiques lock-free

Pour les compteurs et drapeaux, Interlocked évite un lock et fournit des barrières mémoire appropriées.

CAS (Compare-And-Swap) avec Interlocked.CompareExchange pour un toggle/idempotence sans lock.

Volatile & modèle mémoire .NET

Volatile.Read/Write garantit la visibilité entre threads pour des lectures/écritures simples. Pour des opérations composées, utiliser lock ou Interlocked.

Pièges & bonnes pratiques

- Deadlocks: ordre de prise des locks cohérent; timeouts via TryEnter si nécessaire.

- Ne jamais faire d’async/await dans un lock: préférer

SemaphoreSlim pour l’asynchrone.

- Éviter lock(this), lock(typeof(T)), lock sur string; utiliser un objet privé dédié.

- ReaderWriterLockSlim pour lectures majoritaires; Mutex pour inter‑process; SpinLock/SpinWait seulement pour cas très spécialisés.

Performance & choix

-

- Préférer Interlocked pour compteurs chauds; lock pour sections critiques courtes; structures plus haut niveau ("channels", pipelines) pour la coordination.