Ist es sicher, SyncLock und MemoryBarrier aufzurufen, auch wenn Sie nicht in einem separaten Thread sind?

Question

Ein Nachfolger zu this post. Mein Ziel ist es nur eine Calculate zu einer Zeit zu haben, so habe ich eine SyncLock hinzugefügt:

Public Sub Calculate(Optional inBack As Boolean = True) 
    If Not inBack Then 
     InternalCalculate(-1, False) 
    Else 
     If CalcThread IsNot Nothing Then 
      CalcThread.Abort() ' yes, I will replace this 
      CalcThread = Nothing ' XXX 
     End If 
     If CalcThread Is Nothing Then 
      CalcThread = New Threading.Thread(AddressOf InternalCalculate) 
      CalcThread.IsBackground = True 
     End If 
     CalcThread.Start() 
    End If 
End Sub 

Private Sub InternalCalculate(Optional Line As Integer = -1, Optional isBack As Boolean = True) 
    Dim Lock As New Object 
    SyncLock Lock 
     Threading.Thread.MemoryBarrier() ' do this BEFORE a write, right? 
     isRunning = true 
     'do the expensive stuff 
    End SyncLock 
End Sub 

Notiere die isBack. Wenn dies falsch ist, sollte der Code nur in main ausgeführt werden. Dies wird häufig verwendet, wenn ein einzelner Line neu berechnet wird. Also meine Frage ist über die Sicherheit dieser beiden Linien:

SyncLock Lock 
Threading.Thread.MemoryBarrier() 

Es ist mir nicht klar, in the documentation, was passiert, wenn ich diese in Code ausgeführt wird in Haupt nennen. Ich habe den Code hinzugefügt, und es scheint zu laufen, OK, aber ich möchte sicherstellen, dass ich mich nicht zu einem anderen Gotcha öffne, wie Abort. Sind diese OK für beide Anwendungen mit und ohne Gewinde?

Answer 1

Ja, es ist sicher, sie in Single-Thread-Code zu verwenden.

Es gibt jedoch Probleme mit Ihrer InternalCalculate, die es ermöglicht, Code gleichzeitig auszuführen. Bei jedem Aufruf von InternalCalculate wird ein neues Objekt Lock erstellt. Synclock blockiert nur Threads, wenn diese das gleiche Objekt verwenden, also Lock eine Readonly-Membervariable machen.

Wenn Sie dann mehrere Threads ausführen, wird der zweite, dritte, vierte usw. warten, bis der erste, der die Sperre erhält, den Sync Lock Block verlässt. Dann werden die anderen gehen. Also, wenn dies Code ist, der nur einmal ausgeführt werden sollte, sollten Sie das Double Check Lock Pattern überprüfen.

Anstatt MemoryBarriers für das Lesen/Schreiben von flüchtigen Daten hinzuzufügen, würde ich vorschlagen, dass Sie System.Threading.Thread.VolatileRead und System.Threading.Thread.VolatileWrite verwenden. Dann müssen Sie sich nicht merken, in welcher Reihenfolge Sie Ihre Lese-/Schreibvorgänge ausführen.