.net sécurité des filetages

Question

Pourquoi le verrouillage d'un type est-il considéré comme très mauvais? Par exemple, lock(typeof(DateTime)) Je comprends que les méthodes statiques de n'importe quelle classe de .net sont considérées comme sûres de thread, et que les membres d'instance ne le sont pas. Il n'est donc pas nécessaire de verrouiller DateTime pendant que vous l'utilisez. Le livre que je suis en train de lire n'explique pas pourquoi c'est mauvais, il le dit juste. Toute explication sera géniale.

Answer 1

Le CLR maintient une instance unique de chaque type pour chaque AppDomain (et comme Joe souligne dans sa réponse, parfois ils sont même partagés entre un contexte plus large).

Puisque vous ne contrôlez pas accès à des types, vous pouvez vous retrouver bloquer involontairement ou être bloqué par un code complètement différent qui verrouille également votre type. Au lieu de cela, vous devez généralement verrouiller sur les instances privées qui se trouvent dans la même classe que l'opération (ou les opérations associées) que vous souhaitez verrouiller afin de pouvoir contrôler les effets et les blocages du verrou. (Bien qu'il existe aussi des cas où il est logique de se verrouiller sur un objet de synchronisation bien connu qui est destiné à être utilisé dans différents objets.)

Answer 2

De MSDN:

Le mot-clé de verrouillage marque un bloc d'instructions en tant que section critique en obtenant le verrou d'exclusion mutuelle pour un objet donné, en exécutant une instruction, puis en relâchant le verrou. Cette déclaration prend la forme suivante:

Donc, fondamentalement, vous êtes censé verrouiller un objet. Donc, si vous voulez avoir un verrou, vous devriez avoir un objet spécifique que vous verrouillez, par exemple un récipient tel qu'un spécifiquement HashTable ou partagé object utilisé pour verrouiller.

En verrouillant le résultat de typeof(DateTime) vous dites qu'aucun autre objet peut mettre un verrou sur le type. Ceci est trop grossier d'un verrou - en d'autres termes, votre code devrait être en mesure de verrouiller un autre objet DateTime dans un autre endroit dans le code, mais avec votre méthode qui ne sera pas possible.

Answer 3

Outre les raisons déjà mentionnées, un objet de type peut être partagé entre les différents domaines d'application dans le même processus. Par conséquent, le code exécuté dans un AppDomain différent peut bloquer votre application.

Il y a une discussion de ce here.