C # Sperre und Code Analyse Warnung CA2002

7

In meiner Anwendung habe ich ein Formular, das den Synchronisationsprozess startet und aus verschiedenen Gründen möchte ich nur eine Synchronisation gleichzeitig ausführen lassen. Also habe ich ein statisches Bool-Feld zu meinem Formular hinzugefügt, das angibt, ob eine Synchronisierung läuft und eine Sperre hinzugefügt, um dieses Feld auf True zu setzen, wenn es nicht bereits gesetzt war, damit der erste Thread die Synchronisation starten kann, aber wenn es jeden anderen Thread ausführt werde versuchen zu starten wird beendet.

Mein Code ist ungefähr so:

%Vor%

Das funktioniert gut, aber wenn ich Code Analysis in meinem Projekt starte, erhalte ich die folgende Warnmeldung:

  

CA2002: Microsoft.Reliability: 'SynchronizationForm.SynchronizationForm_Shown (Objekt, EventArgs)' sperrt eine Referenz vom Typ 'Type'. Ersetzen Sie dies durch eine Sperre gegen ein Objekt mit starker Identität.

Kann mir jemand erklären, was mit meinem Code nicht stimmt und wie ich ihn verbessern kann, damit die Warnung wegfällt? Was bedeutet es, dass das Objekt eine starke Identität hat?

    
RaYell 23.10.2009, 13:49
quelle

4 Antworten

10

Was falsch ist, ist, dass Sie etwas öffentliches ( typeof(SynchronizationForm) ) sperren, auf das überall von Ihrem Code aus zugegriffen werden kann, und wenn eine andere Thread-Sperre für dieselbe Sache sorgt, erhalten Sie einen Deadlock. Im Allgemeinen ist es eine gute Idee, nur private statische Objekte zu sperren:

%Vor%

Dies garantiert Ihnen, dass nur SynchronizationForm die Sperre besitzen kann.

    
Darin Dimitrov 23.10.2009, 13:53
quelle
6

Von der MSDN-Erklärung der Regel

  

Ein Objekt soll eine schwache Identität haben, wenn direkt über die Grenzen der Anwendungsdomänen hinweg zugegriffen werden kann. Ein Thread, der versucht, eine Sperre für ein Objekt mit einer schwachen Identität zu erhalten, kann von einem zweiten Thread in einer anderen Anwendungsdomäne mit einer Sperre für dasselbe Objekt blockiert werden.

Da Sie nicht unbedingt vorhersagen können, welche Sperren eine andere AppDomain sperrt, und da solche Sperren möglicherweise gemarshallt werden müssten und dann teuer wären, macht diese Regel für mich Sinn.

    
Doug McClean 23.10.2009 13:54
quelle
3

Das Problem ist, dass typeof (SynchronizationForm) kein privates Sperrobjekt ist, was bedeutet, dass jedes andere Stück Code es zum Sperren verwenden könnte, was zu einem Deadlock führen könnte. Zum Beispiel, wenn ein anderer Code das getan hat:

%Vor%

Dann wird Deadlock auftreten. Stattdessen sollten Sie ein privates Sperrobjekt in der SynchronizationForm-Klasse bereitstellen und stattdessen diese sperren.

    
Lee 23.10.2009 13:56
quelle
2
  

Das System.Type -Objekt einer Klasse kann bequem als wechselseitige Ausschlusssperre für statische Methoden der Klasse verwendet werden.

Quelle: Ссылка

Um Dougs Antwort hinzuzufügen, haben Sie hier einen Sperrmechanismus, der nur in statischen Methoden verwendet werden sollte, die in einer Instanzmethode verwendet werden.

    
Paul Turner 23.10.2009 13:59
quelle

Tags und Links