Volatile vs. Interlocked vs. lock

EDIT: Jak wspomniano w komentarzach, w dzisiejszych czasach chętnie używam Interlocked dla przypadków pojedynczej zmiennej Gdzie jest oczywiście w porządku. Kiedy będzie bardziej skomplikowane, wrócę do zamykania...

Użycie volatile nie pomoże, gdy trzeba zwiększyć-ponieważ odczyt i zapis są oddzielnymi instrukcjami. Inny wątek może zmienić wartość po przeczytaniu, ale przed odpisaniem.

"volatile" nie zastępuje Interlocked.Increment! Po prostu upewnia się, że zmienna nie jest buforowana, ale używana bezpośrednio.

Zwiększenie zmiennej wymaga w rzeczywistości trzech operacji:

1. Czytaj
2. increment
3. napisz

Interlocked.Increment wykonuje wszystkie trzy części jako jedną operację atomową.

Albo blokada lub blokada jest tym, czego szukasz.

Volatile zdecydowanie nie jest tym, czego szukasz - po prostu mówi kompilatorowi, aby traktował zmienną jako zawsze zmieniającą się, nawet jeśli bieżąca ścieżka kodu pozwala kompilatorowi zoptymalizować odczyt z pamięci w przeciwnym razie.

Np.

while (m_Var)
{ }

Jeśli m_Var jest ustawione na false w innym wątku, ale nie jest zadeklarowane jako volatile, kompilator może uczynić go nieskończoną pętlą (ale nie oznacza to, że zawsze będzie) poprzez sprawdza w rejestrze procesora (np. EAX, ponieważ do tego właśnie został pobrany m_Var od samego początku) zamiast wysyłać kolejny odczyt do lokalizacji pamięci m_Var (może to być buforowane - nie wiemy i nie obchodzi nas to i to jest punkt spójności bufora x86/x64). Wszystkie wcześniejsze posty innych osób, które wspominały o zmianie kolejności instrukcji, pokazują, że nie rozumieją architektur x86/x64. Volatile nie tworzy barier odczytu/zapisu, jak sugerują wcześniejsze posty mówiące "zapobiega ponownemu uporządkowaniu". W rzeczywistości, dzięki protokołowi MESI, mamy gwarancję, że wynik, który odczytujemy, jest zawsze taki sam na wszystkich procesorach, niezależnie od tego, czy rzeczywiste wyniki zostały wycofane do pamięci fizycznej, czy po prostu znajdują się w pamięci podręcznej lokalnego procesora. Nie będę się zbytnio zagłębiał w szczegóły tego, ale bądźcie pewni, że jeśli to pójdzie źle, Intel / AMD prawdopodobnie wyda procesor recall! Oznacza to również, że nie musimy przejmować się realizacją poza zleceniem itp. Wyniki są zawsze gwarantowane aby przejść na emeryturę w porządku-inaczej jesteśmy wypchani!

Z interlocked Increment, procesor musi wyjść, pobrać wartość z podanego adresu, następnie inkrementować i odpisać-wszystko to mając wyłączną własność całej linii pamięci podręcznej (lock xadd), aby upewnić się, że żadne inne procesory nie mogą zmodyfikować jej wartości.

Z volatile, nadal będziesz mieć tylko 1 Instrukcję (zakładając, że JIT jest wydajny tak jak powinien) - inc dword ptr [m_Var]. Jednak procesor (cpuA) nie prosi o wyłączną własność linii pamięci podręcznej podczas robienia wszystkiego z wersją z blokadą. Jak możesz sobie wyobrazić, oznacza to, że inne procesory mogą zapisać zaktualizowaną wartość z powrotem do m_Var po jej odczytaniu przez cpuA. Więc zamiast teraz zwiększyć wartość dwukrotnie, kończy się tylko raz.

Aby uzyskać więcej informacji, zobacz "zrozumieć wpływ technik Low-Lock w aplikacjach wielowątkowych" - http://msdn.microsoft.com/en-au/magazine/cc163715.aspx

P. s. Co skłoniło do tej bardzo późnej odpowiedzi? Wszystkie odpowiedzi były tak rażąco niepoprawne (szczególnie ta oznaczona jako odpowiedź) w swoim wyjaśnieniu, że musiałem to wyjaśnić każdemu, kto to czyta. wzrusza ramionami

P. P. S. zakładam, że celem jest x86 / x64, a nie IA64 (ma inny model pamięci). Zauważ, że specyfikacja ECMA Microsoftu jest spieprzona, ponieważ określa najsłabszy model pamięci zamiast najsilniejszego (zawsze lepiej jest określić najmocniejszy model pamięci, aby był spójny na różnych platformach - w przeciwnym razie kod, który działałby 24-7 na x86/x64, może w ogóle nie działać na IA64, chociaż Intel zaimplementował podobnie silny model pamięci dla IA64) - Microsoft przyznał to sam - {26]} http://blogs.msdn.com/b/cbrumme/archive/2003/05/17/51445.aspx .

Zablokowane funkcje nie blokują się. Są atomowe, co oznacza, że mogą zakończyć się bez możliwości przełączania kontekstu Podczas przyrostu. Więc nie ma szans na impas lub czekać.

Powiedziałbym, że zawsze powinieneś woleć to od blokady i inkrementacji.

Volatile jest przydatny, jeśli trzeba zapisać w jednym wątku, aby odczytać w innym, i jeśli chcesz, aby optymalizator nie zmieniał kolejności operacji na zmiennej (ponieważ rzeczy dzieją się w innym wątku, że optimizer o tym nie wie). To ortogonalny wybór, jak możesz zwiększyć.

Jest to naprawdę dobry artykuł, jeśli chcesz przeczytać więcej o kodzie bez blokady i właściwym sposobie podejścia do jego pisania

Http://www.ddj.com/hpc-high-performance-computing/210604448

Lock(...) działa, ale może zablokować wątek i spowodować impas, jeśli inny kod używa tych samych blokad w niezgodny sposób.

* jest prawidłowy sposób, aby to zrobić ... znacznie mniej kosztów, jak nowoczesne procesory obsługują to jako prymitywne.

Lotna sama w sobie nie jest poprawna. Wątek próbujący odzyskać, a następnie odpisać zmodyfikowaną wartość może nadal być w konflikcie z innym wątkiem wykonującym to samo.

Popieram odpowiedź Jona Skeeta i chcę dodać następujące linki dla wszystkich, którzy chcą dowiedzieć się więcej o" lotnych " i Interlocked:

Atomiczność, zmienność i niezmienność są różne, część pierwsza - (fantastyczne przygody Erica Lipperta w kodowaniu)

Atomiczność, zmienność i niezmienność są różne, część druga

Atomiczność, zmienność i niezmienność są różne, Część trzecia

Sayonara - (Wayback Maszynowa migawka Webloga Joe Duffy ' ego, jak pojawiła się w 2012)

Zrobiłem test, aby zobaczyć, jak teoria naprawdę działa: kennethxu.blogspot.com/2009/05/interlocked-vs-monitor-performance.html . mój test był bardziej skoncentrowany na CompareExchnage, ale wynik przyrostu jest podobny. Blokowane nie jest konieczne szybsze w środowisku wielu procesorów. Oto wynik testu dla przyrostu na 2-letnim serwerze CPU 16. Należy pamiętać, że test obejmuje również bezpieczny odczyt po zwiększeniu, co jest typowe w świecie rzeczywistym.

D:\>InterlockVsMonitor.exe 16
Using 16 threads:
          InterlockAtomic.RunIncrement         (ns):   8355 Average,   8302 Minimal,   8409 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):   7077 Average,   6843 Minimal,   7243 Maxmial

D:\>InterlockVsMonitor.exe 4
Using 4 threads:
          InterlockAtomic.RunIncrement         (ns):   4319 Average,   4319 Minimal,   4321 Maxmial
    MonitorVolatileAtomic.RunIncrement         (ns):    933 Average,    802 Minimal,   1018 Maxmial

Przeczytaj Threading w C# referencji. Obejmuje tajniki twojego pytania. Każdy z trzech mają różne cele i skutki uboczne.