Czy jest możliwe utworzenie testu pokazującego niepowodzenie podwójnie sprawdzanego blokowania w języku C#?

Question

Oto moje własne narzędzie do podwójnego sprawdzania blokowania: jest to statyczna metoda, do której podajesz kryterium, obiekt synchronizacji i akcję, która ma zostać wykonana.

public static bool RunIf(Func<bool> criterion, object syncObject, Action action) 
{ 
    if (criterion()) 
     lock(syncObject) 
      if (criterion()) 
      { 
       Thread.MemoryBarrier(); 
       action(); 
       return true; 
      } 
    return false; 
} 

ja dać do zrozumienia, że ​​w zależności od specyfikacji C# jest możliwe do optymalizacji zmienić kolejność alokacji pamięci w taki sposób, że bez bariery pamięci, technika ta może dać fałszywie dodatnich i wykonać działanie, kiedy nie powinno.

W moim małym świecie, jeśli taka awaria jest możliwa, powinno być również możliwe opracowanie testu, który wykaże awarię konsekwentnie przez trafienie scenariusza wystarczająco mocno z wystarczającą liczbą równoległych przypadków testowych. Tego rodzaju test szukam od około roku, ale do tej pory narysowałem pustkę. Czy ktoś może mi pokazać test, który:

1. pokazuje awarię tej metody w przypadku braku bariery pamięci;

2. pokazuje swój sukces po powtórzeniu testu z przywróconą barierą pamięci?

Answer 1

Nie, to nie jest możliwe, aby przetestować niedeterministycznego zachowanie (lub przynajmniej, jeśli nie następnie ujemny wynik jest wciąż niejednoznaczne).

Answer 2

Niemożliwe jest skonstruowanie takiego testu, ponieważ instrukcja "blokada" tworzy już pełne ogrodzenie (to jest ogrodzenie przejmujące i zwalniające) dla zablokowanego bloku instrukcji. Zatem dodatkowy Thread.MemoryBarrier() jest zbędny i nie daje żadnego efektu.

Tak więc, w zależności od tego, co zrobił delegat criterion, twoja konstrukcja RunIf jest bezpieczna lub całkowicie niepotrzebna.

Co mam na myśli to, że jeśli przekazany criterion delegata czerpie swoją wartość zwracaną od stanu zmiennego, a ten stan zmienny nie jest zabezpieczony (bezpośrednio lub pośrednio) przez tego samego syncObject, ten kod nie jest bezpieczny i RunIf zasadniczo nie ma żadnego efektu, z wyjątkiem otaczania instrukcji wykonanych podczas drugiego połączenia z delegatem criterion z pełnym ogrodzeniem.