Ich habe ein kleines Testprogramm geschrieben und war überrascht, warum lock {} solution schneller funktioniert als lock-free, aber mit [ThreadStatic] Attribut über der statischen Variable.
[ThreadStatic] Snippet:
%Vor%Sperren {} Snippet:
%Vor%Auf meinem Computer dauert das erste Snippet 4,2 Sekunden; Sekunden - 3,2 Sekunden, das ist 1 Sekunde schneller. Ohne ThreadStatic und Sperre - 1,2 Sekunden.
Ich bin neugierig, warum [ThreadStatic] Attribut in diesem einfachen Beispiel so viele zur Programmlaufzeit hinzufügt?
UPDATE : Es tut mir sehr leid, aber diese Ergebnisse beziehen sich auf DEBUG build. Für RELEASE eins habe ich völlig unterschiedliche Zahlen: (1.2; 2.4; 1.2). Für% co_de waren die Zahlen (4.2; 3.2; 1.2).
Für DEBUG build scheint es also keine RELEASE Leistungseinbuße zu geben.
Für RELEASE Build scheint es fast keine [ThreadStatic] Leistungseinbuße zu geben (nur eine kleine Strafe für moderne CPUs).
Hier kommt der dis-Assembly-Code für ms_Acc += one ; Für RELEASE Optimierung ist aktiviert:
Nein [ThreadStatic] , DEBUG :
Nein [ThreadStatic] , RELEASE :
[ThreadStatic] , DEBUG :
[ThreadStatic] , RELEASE :
Sie haben zwei Codezeilen, die ms_Acc aktualisieren. Im Fall lock haben Sie eine einzige Sperre für beide, während sie im Fall ThreadStatic einmal für jeden Zugriff auf ms_Acc auftritt, d. H. Zweimal für jede Iteration Ihrer Schleife. Dies ist im Allgemeinen der Vorteil der Verwendung von lock . Sie können die gewünschte Granularität auswählen. Ich vermute, dass der RELEASE-Build diesen Unterschied optimiert hat.
Ich würde gerne sehen, ob die Performance sehr ähnlich oder identisch wird, wenn Sie die for-Schleife in einen einzigen Zugriff auf ms_Acc ändern.
Tags und Links c# multithreading threadstatic