Wielowątkowa paranoja

Yup-użyj barier pamięci, aby zapobiec zmianie kolejności instrukcji w razie potrzeby. W niektórych kompilatorach C++ słowo kluczowe volatile zostało rozszerzone, aby wstawić Ukryte bariery pamięci dla każdego odczytu i zapisu - ale nie jest to przenośne rozwiązanie. (Podobnie z połączonymi interfejsami API* win32). Vista dodaje nawet kilka nowych drobnoziarnistych interfejsów API, które pozwalają określić semantykę odczytu lub zapisu.

Niestety, C++ ma tak luźny model pamięci, że każdy taki kod będzie nie-przenośny do pewnego stopnia i będziesz musiał pisać różne wersje dla różnych platform.

Jak powiedziałeś, z powodu zmiany kolejności na poziomie pamięci podręcznej lub procesora, faktycznie potrzebujesz jakiejś bariery pamięci, aby zapewnić właściwą synchronizację, szczególnie dla wielu procesorów (a zwłaszcza na platformach innych niż x86). (Dano mi wierzyć, że systemy jednoprocesorowe nie mają tych problemów, ale nie cytujcie mnie na ten temat- - - jestem zdecydowanie bardziej skłonny grać bezpiecznie i robić synchronizowany dostęp i tak.)

Napotkaliśmy problem, choć na procesorach Itanium, gdzie Zmiana kolejności instrukcji jest bardziej agresywna niż x86/x64.

Poprawka polegała na użyciu instrukcji z blokadą, ponieważ nie było (w tym czasie) sposobu mówienia kompilatorowi, aby po prostu powiedział, ale bariera zapisu po przypisaniu.

Naprawdę potrzebujemy rozszerzenia języka, aby poradzić sobie z tym czysto. Użycie volatile (jeśli jest obsługiwane przez kompilator) jest zbyt gruboziarniste dla przypadków, w których próbujesz wycisnąć tyle wydajność z kawałka kodu, jak to możliwe.

Czy to kiedykolwiek problem na prawdziwym sprzęcie?

Absolutnie, szczególnie teraz, gdy przenosimy się na wiele rdzeni dla obecnych i przyszłych procesorów. Jeśli jesteś zależny od uporządkowanej atomiczności implementacji funkcji w swojej aplikacji i nie jesteś w stanie zagwarantować tego wymogu za pośrednictwem wybranej platformy lub korzystania z synchronizacji prymitywów, w warunkach wszystkie, tj. Przejście klienta z jednordzeniowego procesora do wielordzeniowego procesora, to po prostu czekasz na problem zaistnieć.

Cytowanie z cytowanego artykułu o herbie Sutter (drugi)

Uporządkowane zmienne atomowe są pisane na różne sposoby na popularnych platformach i środowiskach. Na przykład:

• volatile W C#/. Net, jak w volatile int.
• volatile lub * Atomic* w Javie, jak w volatile int, AtomicInteger.
• atomic<T> W C++0x, nadchodzący Standard ISO C++, jak w atomic<int>.

Nie widziałem jak C++0x implementuje atomicity więc jestem nie można określić, czy nadchodząca funkcja językowa jest czystą implementacją biblioteki, czy też zależy również od zmian w języku. Możesz przejrzeć propozycję, aby sprawdzić, czy można ją włączyć jako niestandardowe rozszerzenie do obecnego łańcucha narzędzi, dopóki nowy standard nie będzie dostępny, może być nawet dostępny już dla twojej sytuacji.

Jest to problem na prawdziwym sprzęcie. Mój przyjaciel pracuje dla IBM i zarabia na życie przede wszystkim poprzez wykrywanie tego rodzaju problemów w kodach klientów.

Jeśli chcesz zobaczyć, jak źle może być, poszukaj prac naukowych na temat modelu pamięci Java (a teraz również modelu pamięci C++). Biorąc pod uwagę zmianę kolejności, jaką może zrobić prawdziwy sprzęt, próba ustalenia, co jest bezpieczne w języku wysokiego poziomu, jest koszmarem.

Nie to nie jest bezpieczne i jest dostępny prawdziwy sprzęt, który wykazuje ten problem, na przykład model pamięci w chipie powerpc na Xboxie 360 pozwala na zmianę kolejności zapisu. Jest to pogłębione przez brak barier w wewnętrznych, zobacz ten artykuł na msdn aby uzyskać więcej szczegółów.

Odpowiedź na pytanie "czy to bezpieczne" jest z natury niejednoznaczna.

Jest zawsze bezpieczny, nawet dla sobowtórów, w tym sensie, że Twój komputer nie zapali się. Jest to bezpieczne, w tym sensie, że zawsze otrzymasz wartość, którą int trzymał w pewnym momencie w przeszłości, To nie jest bezpieczne, w tym sensie, że możesz uzyskać wartość, która jest/będzie aktualizowana przez inny wątek.

"Atomic" oznacza, że otrzymujesz drugą gwarancję. Ponieważ double zwykle nie jest atomowy, możesz dostać 32 stare i 32 nowe bity. To niebezpieczne.

Kiedy zadałem pytanie najbardziej interesował mnie uniprocesor powerpc. W jednym z Komentarzy InSciTek Jeff wspomniał o instrukcji powerpc SYNC i ISYNC. Tam, gdzie klucz do ostatecznej odpowiedzi. Znalazłem to Tutaj {[2] } na stronie IBM.

Artykuł jest duży i dość gęsty, ale zabranie jest nie, nie jest bezpieczne. W starszych PowerPC ' s optymalizatory pamięci, gdzie nie jest wystarczająco wyrafinowany, aby spowodować problemy na uniprocesor. Jednak nowsze są znacznie bardziej agresywny i może złamać nawet prosty dostęp do globalnego int.