Generics: Thread-sicherer Cache mit TMonitor und Double-Checked Locking – wo es in Delphi schiefgeht

Poniedziałek, 09:12: Usługa działała od tygodni bezobjawowo. Potem pojawia się szczyt obciążenia, nowy klient, nowy stan danych – i nagle w dzienniku zdarzeń wpis o sporadycznej Access Violation. Nie stale. Nie da się tego od razu odtworzyć. Po restarcie: znowu spokój. W kodzie znajduje się „sprytne” miejsce, które miało wszystko poprawić: Double-Checked Locking w generycznym cache’u. Zdanie brzmi znajomo: „Gdy cache jest rozgrzany, oszczędzamy sobie locka.”

Błąd w tym założeniu: Double-Checked Locking nie czyni cache’a bezpiecznego dla wątków w Delphi automatycznie szybszym i poprawnym. Często sprawia jedynie, że staje się on trudniejszy do udowodnienia – a w przypadku błędu znacznie trudniejszy do debugowania. Ta weryfikacja błędu pokazuje, gdzie w Delphi z System.TMonitor konkretnie może coś pójść nie tak, które przypadki brzegowe w generycznych cache’ach naprawdę się liczą i jakie wzorce lepiej stosować w praktyce.

cache bezpieczny dla wątków w Delphi: Weryfikacja błędu „DCL + TMonitor to przecież standard”

Double-Checked Locking (DCL) opiera się na prostej idei: najpierw bez blokady sprawdza się, czy wpis w cache istnieje. Tylko jeśli nie, stosuje się blokadę, przeprowadza ponowne sprawdzenie, a następnie tworzy i zapisuje element. Dzięki temu kosztowne blokady mają zniknąć w „stanie rozgrzanym”.

Problemem nie jest pomysł, lecz założenia. DCL jest poprawne tylko wtedy, gdy zapewnione jest, że żaden wątek nie zobaczy referencji do obiektu, którego inicjalizacja nie jest jeszcze w pełni widoczna. Bez zdefiniowanych barier pamięci (Memory Barriers), semantyki volatile lub atomików, przestawianie/widoczność (Reordering/Visibility) może spowodować, że inny wątek uzna coś za dostępne „zbyt wcześnie”.^[Quelle] Dokumentacja Error-Prone koncentruje się na Javie, ale sedno jest uniwersalne: DCL zależy od jednoznacznych reguł modelu pamięci, a nie od intuicji.

Dla Delphi dochodzi drugi aspekt: System.TMonitor jest opisany jako mechanizm monitora (Enter/Exit/TryEnter) wraz z zachowaniem zmiennej warunkowej (Wait/Pulse/PulseAll).^[Quelle] To pomaga przy prawidłowym oczekiwaniu i sygnalizowaniu. DocWiki w tej formie nie daje jednak wyraźnej obietnicy, że każda forma publikacji oparta na DCL będzie bezpieczna bez dodatkowych środków. Ta luka ma praktyczne znaczenie: kto stosuje DCL, musi być w stanie uzasadnić poprawność — a nie tylko liczyć na wydajność.

Specyficzna pułapka w Delphi: TMonitor nie zawsze jest monitorem

Zanim w ogóle zaczniemy dyskusję o lockach, warto krótko sprawdzić rzeczywistość: w Delphi istnieją dwa wyraźne typy TMonitor o zupełnie innym znaczeniu. System.TMonitor to monitor wątku. Vcl.Forms.TMonitor opisuje monitor ekranowy w konfiguracji wielomonitorowej.^[Quelle]

Brzmi to jak pułapka dla początkujących, ale występuje również w dużych bazach kodu: jednostki są dołączane później, nazwy są w dyskusjach skracane, ktoś mówi „używamy TMonitor”, i nagle połowa osób ma na myśli coś innego. Praktyczna zasada: jeśli chodzi o synchronizację, w kodzie (lub w notatkach architektonicznych) powinno być jednoznacznie wskazane System.TMonitor — w razie potrzeby w pełni kwalifikowane, żeby nie było wątpliwości.

Gdzie Double-Checked Locking w Delphi rzeczywiście zawodzi

Kiedy DCL zawodzi, rzadko wygląda to jak „klasyczny” błąd synchronizacji. Wygląda jak losowy chaos. Szczególnie niebezpieczne jest to w przypadku generycznych cache’y, ponieważ cache jest wtedy użyty w wielu modułach, a błąd rozchodzi się na szeroką skalę.

1) Widoczność i częściowa inicjalizacja: referencja „da”, zawartość nie jest stabilna

Typowy skutek DCL: wątek A tworzy obiekt i zapisuje referencję gdzieś (cache, pole, wartość w słowniku). Wątek B sprawdza bez locka, widzi „da” i korzysta z obiektu. Jeśli A udostępnił referencję, ale nie ma gwarancji, że wszystkie zainicjalizowane pola, wewnętrzne listy lub zależne struktury są już widoczne dla B, powstaje stan pozornie logicznie niemożliwy: obiekt istnieje, ale pole wewnętrzne ma nadal wartość domyślną lub nil. To jest sedno ostrzeżeń dotyczących DCL: bez gwarancji modelu pamięci inny wątek może zobaczyć referencję, zanim inicjalizacja zostanie w pełni „opublikowana”.^[Quelle]

Dlaczego to jest tak nieprzyjemne? Ponieważ awaria często nie zdarza się w cache. Zdarza się później – przy dostępie do właściwości, która w zasadzie powinna być gwarantowana. Wówczas stacktrace wskazuje na zupełnie inne obszary (Mapper, Serializer, dostęp do danych), a miejsce synchronizacji wydaje się niewinne.

2) Container-Sicherheit: TDictionary ist kein paralleler Read-Container bei concurrent Writes

Wiele wariantów DCL koncentruje się na „budowie obiektu”. Zapominają o kontenerze. Ein TDictionary nie jest zaprojektowany do tego, by jeden wątek zapisywał (Add/Insert/Resize/Rehash), podczas gdy inny wątek jednocześnie bez Lock czyta (TryGetValue/ContainsKey). Nawet gdy konstrukcja wartości byłaby perfekcyjnie opublikowana, dostęp do wewnętrznych struktur słownika może już kolidować, na przykład podczas Rehash/Resize. DCL staje się wtedy nie tylko problemem widoczności, lecz konkretnym konfliktem struktury danych.

To moment, w którym DCL staje się szczególnie podstępny: niezastrzeżony pierwszy check nie jest tylko „optymalizacją”, lecz w pewnych okolicznościach zwyczajnie niedozwolonym dostępem do mutującego kontenera.

3) „Im Worst Case wird zweimal gebaut“ ist selten harmlos

DCL bywa często broniony wzruszeniem ramion: „W najgorszym wypadku zbuduje się dwa razy, ale ostatecznie będzie raz w cache.” To prawda tylko wtedy, gdy builder jest idempotentny i nie ma efektów ubocznych. W rzeczywistych bazach kodu cache’e często budują jednak takie rzeczy jak przygotowane zapytania, metadane RTTI, parsery, mappery, konfiguracje, klientów HTTP lub zasoby oparte na plikach. Podwójna inicjalizacja może wtedy podwoić zużycie zasobów, zarejestrować stany dwukrotnie lub stworzyć okienka czasowe, które w określonych warunkach ekskalują.

4) Reentrancy und Lock-Ordnung: Builder ruft wieder in den Cache

Inny przypadek brzegowy, który w przeglądach kodu łatwo umyka: builder dla klucza X pośrednio wywołuje kod, który z kolei używa tego samego cache’a (lub innego cache’a). Jeśli kolejność blokad nie jest stabilna, powstają deadlocki lub długotrwałe łańcuchy blokad. DCL zaostrza problem, bo łatwo dodać dodatkowe blokady („tylko podczas build”), po czym przestaje być jasne, które ścieżki i kiedy są zablokowane.

Was die Quellen für die Praxis tragen – und wo die Grenzen bleiben

DocWiki dotyczące System.TMonitor jest rzetelne, jeśli chodzi o zachowanie monitora: Enter/Exit jako wzajemne wykluczanie, Wait jako atomowe zwolnienie i późniejsze ponowne przejęcie blokady, Pulse/PulseAll do wybudzania oczekujących wątków.^[Źródło] Z tego wynika dla eksploatacji: jeśli cache wewnętrznie pracuje na warunkach (np. „jeden wątek buduje, inne czekają”), da się to zasadniczo wyrazić czysto.

Granica: Z tej dokumentacji nie da się wprost wyprowadzić twardego stwierdzenia, że DCL bez dodatkowych mechanizmów Atomics/Memory-Barrier zawsze będzie poprawne. Właśnie dlatego interesujący jest konserwatywny sposób postępowania, który pokazuje Net-Base w przykładowym Delphi dla cache typu: dostęp do słownika jest w całości chroniony przez TMonitor.Enter/Exit, czyli nie DCL, lecz „always lock“. Dodatkowo zalecane jest Pre-Warming/Preload, aby zredukować contention, nie zwiększając ryzyka poprawności.^[Źródło] Konsekwencja praktyczna: kto wprowadza DCL, by uniknąć blokad, powinien najpierw sprawdzić, czy Pre-Warming i czysta kapsułka blokad dają taki sam efekt — przy znacznie mniejszej liczbie pułapek brzegowych.

Odporne alternatywy: trzy wzorce cache, które dają się dobrze eksploatować

Jeżeli cache ma działać stabilnie w codziennej eksploatacji, liczy się nie tylko przepustowość, ale też utrzymywalność: jak szybko podczas incydentu da się ustalić, czy cache jest zaangażowany? Jak klarowne jest pojęcie blokady? I jak łatwo przetestować zachowanie?

Always-Lock: świadomie nudne – i właśnie dlatego odporne na obciążenia

Always-Lock oznacza: odczyt i zapis słownika odbywają się wyłącznie wewnątrz monitora. Na pierwszy rzut oka wygląda to jak anty-wydajnościowe podejście. W wielu obciążeniach biznesowych jest to jednak najszybsza droga do systemu, którym będzie się dało zarządzać także za sześć miesięcy. I: gdy pojawi się konflikt o zasoby, można go zmierzyć i celowo zaadresować (Pre-Warming, granularyzacja, RW-Lock) – bez ryzyka naruszenia podstawowej poprawności.

Wspomniana implementacja cache’a w przykładzie Net-Base idzie dokładnie tą drogą: wspólny słownik jest chroniony przez TMonitor.Enter/Exit, zamiast eksperymentować z DCL.^[Źródło]

Reader/Writer-Lock: dla cache’ów o rzeczywiście dominujących odczytach

Jeśli po rozgrzewce cache jest praktycznie tylko odczytywany, Reader/Writer-Lock może mieć sens: wiele wątków może czytać równolegle, tylko ścieżka zapisu jest ekskluzywna. To zmniejsza blokady, nie zostawiając jednak kontenera bez ochrony.

Ważniejsza jest tu mniej klasa niż dyscyplina: kod musi surowo rozgraniczać, kiedy następuje odczyt, a kiedy zapis. Półoptymalizacje („erst read lock, dann doch write lock“) szybko wprowadzają złożoność, która później kończy się deadlockami lub trudno wytłumaczalnymi stanami oczekiwania.

Pre-Warming: zysk wydajności bez synchronizacyjnej akrobatyki

Pre-Warming celowo przesuwa pracę poza hot path. Zamiast pozwalać, żeby pierwszy prawdziwy request pod obciążeniem musiał wypełniać cache, ładujesz typowe klucze wcześniej, selektywnie. Net-Base wyraźnie rekomenduje to podejście jako uzupełnienie cache’a chronionego monitorem, aby zredukować konflikt o zasoby.^[Źródło]

Gdy DCL rzeczywiście trafia na stół: procedura możliwa do weryfikacji

Czasami nadejdzie moment, w którym Always-Lock mierzalnie już nie wystarcza, a RW-Lock sam w sobie nie jest wystarczający lub nie pasuje czysto. Wtedy zaczyna się dyskusja o DCL. Najpóźniej wtedy należy traktować to jak funkcję-ryzyko: z jasnymi regułami, testami i mierzalnymi kryteriami – nie jako „Micro-Optimierung“ w pobocznym commicie.

1. Zabezpieczyć dostęp do kontenera: Upewnij się, że nie może mieć miejsca niezastrzeżony dostęp do mutującego TDictionary. Jeśli zapisy są możliwe, odczyty muszą być chronione (Monitor/RW-Lock) albo struktura danych/faza musi być zaprojektowana tak, by równoległe odczyty były gwarantowanie bezpieczne.
2. Zdefiniować punkt publikacji: Wartość uznaje się za „opublikowaną“, dopiero gdy jest w pełni zainicjalizowana. Nie umieszczać referencji w cache i dopiero potem dalej konfigurować.
3. Oceń podwójne budowanie: Sprawdź, czy Builder ma faktyczne efekty uboczne (uchwyty, pliki, wywołania DB, rejestracje). Jeśli tak, „build twice” nie jest już nieszkodliwym Worst Case, lecz ryzykiem operacyjnym.
4. Nie zgaduj widoczności pamięci: Jeśli chcesz czytać bez locka, potrzebujesz wiarygodnego uzasadnienia, dlaczego wątek nie może zobaczyć niedokończonego stanu. Bez wyraźnej podstawy DCL staje się poleganiem na szczegółach implementacji.
5. Powtarzalne testy obciążeniowe: Zbuduj test, który wielokrotnie w wielu wątkach odpyta ten sam klucz, włącznie ze sztucznymi opóźnieniami w Builderze. Pojedyncze udane uruchomienie nie jest dowodem.

Jeśli punkt 4 nie da się jednoznacznie odpowiedzieć, wynik kontroli jest często prosty: nie wprowadzać DCL jako domyślu, lecz rozwiązać problem przez Pre-Warming, RW-Lock lub zmianę granularności cache.

Debugowanie: ujawnianie warunków wyścigu w cache zamiast ich ignorowania

Breakpointy przy warunkach wyścigu często są kontrproduktywne, bo zmieniają tempo. Celowe sprowokowanie konfliktu i logowanie w sposób pozwalający odtworzyć chronologię jest bardziej użyteczne.

Objawy typowe dla DCL lub warunków wyścigu w cache

• Sporadyczne Access Violations podczas operacji na słownikach (TryGetValue, Add, ContainsKey) lub w dalszym kodzie, który korzysta z pozornie „gwarantowanie zainicjalizowanych” wartości.
• Podwójna inicjalizacja tego samego klucza pomimo użycia cache.
• Deadlocki lub długie zawieszenia pojawiające się tylko przy równoległości (szczególnie przy zagnieżdżonych cache’ach lub łańcuchach blokad).
• Błędy występują częściej w Release niż w Debug lub tylko na wybranych maszynach.

Telemetria, która naprawdę pomaga

Zaloguj dla dostępów do cache: Thread-ID, Key, fazę (First-Check, Lock-Enter, Second-Check, Build-Start, Build-Ende, Publish) oraz czas trwania. Uzupełnij przy użyciu monitora opcjonalnie pomiarami opartymi na TryEnter, aby zobaczyć czasy oczekiwania. Celem nie jest „dużo logu”, lecz czytelny przebieg, który podczas incydentu pokaże, czy dostęp do kontenera odbywa się poza ochroną lub czy buildy przebiegają równolegle.

Rzeczywistość wydajności: dlaczego TMonitor może „nagle wydawać się kosztowny”

Częstą przyczyną rozważań o DCL jest rzeczywisty ból wydajności: contention na blokadach zjada przepustowość. Nie każde z tych zjawisk to argument za DCL — często to wskazówka na szczegóły skalowania.

Istnieją analizy wskazujące, że TMonitor może wykazywać potencjalne efekty wydajnościowe przy dużej równoległości, np. przez cache-line contention/false sharing w strukturach wewnętrznych.^Źródło To nie jest argument poprawności przeciwko monitorom, lecz dobry przypomnienie: kto chce optymalizować, powinien najpierw mierzyć, a potem dobierać odpowiednie środki.

Typowe, często mniej ryzykowne środki zamiast DCL:

• Pre-Warming, aby Builder nie pracował pod obciążeniem.
• Zmiana granularności cache (mniej kluczy, mniej zapisów, mniej zmian rozmiaru).
• Skrócenie ścieżki zapisu (praca builda poza blokadą, przy jednoczesnym chronieniu dostępu do kontenera).
• RW-Lock zamiast monitora, gdy dominują odczyty.

Kiedy nakład pracy na wątkowo-bezpieczny cache się opłaca — a kiedy nie

Generczny cache to infrastruktura. Opłaca się, gdy wielokrotnie zastępuje kosztowne operacje (RTTI-Scanning, złożone mappery, parsery, konfiguracje) i gdy istnieje rzeczywista równoległość (serwis, job-worker, przetwarzanie oparte na taskach, wiele jednoczesnych requestów).

Często jest narzutem, gdy:

• dotyczące ścieżki kodu praktycznie uruchamiane są tylko w wątku UI,
• wartości są niewielkie i przynoszą praktycznie żadne mierzalne korzyści,
• Cache wpływa pośrednio na logikę istotną dla bezpieczeństwa lub rozliczeń, ale optymalizacja ma charakter jedynie spekulatywny.

Moment, w którym robi się „czysto”

Double-Checked Locking w code review często wygląda na „optymalizację dla profesjonalistów”. W Delphi w przypadku generycznych Cache’ów szybko staje się jednak mieszanką ryzyka kontenera, kwestii widoczności i trudno odtwarzalnych wzorców błędów. Czysta droga jest na ogół taka: najpierw zapewnić poprawność i możliwość dowodu (Always-Lock lub Reader/Writer), potem zastosować Pre-Warming i pomiary, a dopiero na końcu – jeśli w ogóle – dyskutować DCL dla ściśle ograniczonych przypadków.

Jeśli chcecie ustabilizować istniejący Cache lub zaplanować modernizację tak, by współbieżność w działaniu nie stała się loterią, warto wykonać krótką techniczną analizę na podstawie waszych konkretnych wzorców dostępu i profili obciążenia. Skontaktujcie się.

Dla tego tematu ważne są także Delphi Tmonitor i Double-Checked Locking Delphi. Artykuł porządkuje te aspekty w przejrzysty sposób i pokazuje, na co zwracać uwagę w praktyce.

Omów projekt lub plan modernizacji z Net-Base.