LOCK |
Verrouille |
|---|---|
| C# (C Sharp) | |
Syntaxe
|
lock (variable) { ... } |
Paramètres
| Nom | Description |
|---|---|
| variable | Ce paramètre permet d'indiquer la variable objet à verrouiller. |
Description
Ce mot réservé permet d'indiquer l'exécution d'un bloc d'instruction dans un contexte de section critique.
Remarques
- Le mot clef lock permet de garantir l'accès exclusif à une section de code critique.
- En C#, il est souvent utilisé pour synchroniser les accès à une ressource partagée entre plusieurs processus légers. Il empêche deux processus légers d'entrer simultanément dans la même portion de code protégée par le même verrou.
- L'objet utilisé comme paramètre de lock sert de "verrou" (mutex implicite) : Il est courant d'utiliser un objet privé dédié à cela, comme private object _lock = new object();, afin d'éviter les effets de bord. Il ne faut jamais utiliser this comme verrou, surtout dans les bibliothèques, car cela peut entraîner des blocages inattendus si d'autres parties du code utilisent aussi this pour verrouiller.
- Le bloc lock est équivalent à une utilisation explicite de Monitor.Enter et Monitor.Exit : lock est en fait du sucre syntaxique encapsulant un appel à Monitor avec une gestion automatique des exceptions. Cela garantit que le verrou est toujours libéré, même en cas d'erreur, ce qui réduit le risque de deadlocks.
- Utiliser lock améliore la sécurité des données mais peut réduire la performance : En bloquant l'exécution parallèle sur certaines sections critiques, on limite le risque de conditions de course (race conditions), mais au prix d'un potentiel ralentissement si de nombreux processus légers attendent leur tour.
- Le verrouillage via lock doit être aussi court que possible : Il est fortement déconseillé d'exécuter du code long, ou susceptible de bloquer (exemple : accès réseau, d'entrée/sortie disque), à l'intérieur d'un bloc lock. Plus le verrou est maintenu longtemps, plus le risque de blocages et de contention augmente.
- lock ne protège pas contre toutes les erreurs de concurrence : Il ne suffit pas d'utiliser lock pour rendre une application multi-processus léger sécurisée. Il faut également choisir les bons verrous, éviter les verrous imbriqués, et bien concevoir l'architecture pour ne pas introduire de deadlocks ou de starvation.
- Il est important d'utiliser des objets privés et stables pour lock : L'objet passé à lock doit rester le même pendant toute la durée de vie de l'application, et ne jamais être modifié ou exposé publiquement. Utiliser une propriété ou un objet public comme verrou peut rendre le code vulnérable à des interférences externes.
- Le mot clef lock ne fonctionne que sur des références d'objet, pas sur des types valeur : Par exemple, vous ne pouvez pas faire lock(5) ou lock(true); le compilateur le refusera. Cela s'explique par le fait que les types valeur sont copiés en mémoire, donc ils ne peuvent pas servir de points de synchronisation fiables.
Dernière mise à jour : Mardi, le 26 janvier 2016