VB.net SyncLock objet

Question

J'ai toujours vu des exemples de personnes qui utilisent SyncLock

Private Lock1 As New Object ' declaration 
    SyncLock Lock1 ' usage 

mais pourquoi? Dans mon cas spécifique, je verrouille une file d'attente pour éviter les problèmes de multi-threading Enqueueing et Dequeueing mes données. Est-ce que je peux verrouiller l'objet Queue lui-même, comme ceci?

Private cmdQueue As New Queue(Of QueueItem) ' declaration 
    SyncLock cmdQueue ' usage 

Toute aide appréciée. Merci.

modifier:

merci pour toutes les réponses, mais la réponse de tcarvin était ce que je cherchais. La file d'attente est privée de mon objet Comms singleton qui met en attente de nouveaux messages à envoyer (exposée par une méthode Send), la file d'attente est consommée dans un thread de travail dans cet objet un message à la fois et le seul code sont un appel à Enqueue et Dequeue.

Answer 1

Sage conseils des autres affiches à coup sûr. Mais la réponse est Oui, vous pouvez utiliser l'objet File d'attente pour verrouiller. Vous pouvez utiliser n'importe quel objet. Et dans votre extrait de code, vous avez déclaré l'instance de votre file d'attente privée, évitant ainsi que quelqu'un d'autre ne se bloque sur votre objet file d'attente (en supposant que vous ne transmettiez pas l'objet en dehors de votre classe). Les meilleures pratiques suggèrent cependant d'utiliser un objet dédié de telle sorte que, plus tard, quelqu'un ne change pas votre code et expose ensuite cet objet de file d'attente utilisé pour le verrouillage.

Answer 2

Le problème est que d'autres peuvent verrouiller votre objet et que ce serait hors de votre contrôle. Voir la meilleure pratique de Microsoft sur ce lock statement

Answer 3

Ceci est une idée fausse commune sur les verrous. Le travail d'un verrou est à code de bloc, de ne pas communiquer la sécurité du fil sur un objet. L'objet est là uniquement pour suivre l'état d'un verrou. Et puisque vous voulez bloquer un spécifique bit de code, vous aurez besoin d'un objet spécifique pour stocker l'état de verrouillage. Une file d'attente publique n'est pas assez spécifique, elle est destinée à être utilisée par un autre code ailleurs. Et s'il utilise aussi incorrectement l'objet queue pour bloquer son propre code, les chances d'un problème d'interblocage sont élevées.

La notion de verrouillage des objets pour mettre en œuvre la sécurité du fil existe réellement, elle fait l'objet de recherches intenses qui ne semblent jamais arriver à ma machine. Il s'appelle STM, "logiciel de mémoire transactionnelle". Article Wikipedia is here.

Answer 4

Je pense que ce que vous faites est une mauvaise pratique, puisque l'objet verrouillé doit rester inchangé. Puisque vous verrouillez sur un Queue(Of QueueItem) puis vous DEQUEUE de la même file d'attente, l'objet change et, comme indiqué ici: https://msdn.microsoft.com/en-us/library/3a86s51t.aspx (2ème règle),

Le mécanisme exige que l'objet de verrouillage reste inchangé.

Alors vous devriez faire comme ce Public StatusObject As New Object et verrouiller sur elle