Poisoning Mutex wykorzystuje flagę boolean w wewnętrznym stanie blokady, która jest atomowo ustawiana na true, gdy występuje panika, gdy strażnik jest trzymany. Podczas fazy odwracania, implementacja Drop strażnika wykrywa panikujący wątek za pomocą std::thread::panicking() i oznacza Mutex jako zatruty przed zwolnieniem podstawowej blokady OS. Kolejne wywołania lock() sprawdzają tę flagę; jeśli jest ustawiona, zwracają Err(PoisonError<MutexGuard<T>>) zamiast Ok, zmuszając wywołującego do uznania, że chronione dane mogą naruszać swoje strukturalne inwarianty z powodu częściowej modyfikacji przerwanej przez panikę.
W rozproszonym silniku przetwarzania dokumentów wątek roboczy w tle trzyma Mutex chroniący dużą DocumentCache podczas wykonywania złożonej procedury formatowania. W połowie aktualizacji wewnętrznych indeksów BTreeMap w pamięci podręcznej, wątek wpada w panikę z powodu nieoczekiwanego błędnego wejścia. Mechanizm odwracania uruchamia implementację Drop strażnika, która wykrywa stan paniki i atomowo truje Mutex przed zwolnieniem blokady na poziomie OS, zapewniając, że uszkodzona częściowa struktura drzewa nie może być dostępna przez innych pracowników bez wyraźnego uznania.
Jedna z potencjalnych strategii odzyskiwania polega na natychmiastowym zakończeniu procesu po wykryciu błędu zatrucia podczas kolejnego nabycia blokady. Gwarantuje to, że żadne uszkodzone dane nigdy nie trafią do pamięci trwałej lub odpowiedzi klientów, spełniając surowe wymagania dotyczące integralności. Jednak takie podejście poświęca dostępność, ponieważ wymusza zimny restart całej usługi i unieważnia wszelką ważną pracę wykonaną przez niezwiązane wątki, co prowadzi do nieakceptowalnego przestoju podczas intensywnych okien przetwarzania.
Drugie podejście wykorzystuje PoisonError::into_inner(), aby wyodrębnić strażnika i kontynuować operacje, skutecznie ignorując flagę zatrucia pod założeniem, że dane są prawdopodobnie strukturalnie prawidłowe. Chociaż zachowuje to czas działania, istnieje ryzyko katastrofalnych awarii kaskadowych, gdy kolejne odczyty napotykają pozostawione przez panikujący wątek zwisające wskaźniki lub naruszenia inwariantów, co może powodować wtórne paniki lub cichą korupcję danych, która propaguje się w analizach w dół strumienia i trwałych bazach danych.
Wybrane rozwiązanie implementuje mechanizm transakcyjnego wycofywania: po wychwyceniu błędu zatrucia, system jawnie usuwa skażoną DocumentCache, przywraca znaną dobrego, niezmienną migawkę z Write-Ahead Log (WAL), która jest przechowywana na osobnej woluminie NVMe, i uruchamia nowy wątek roboczy z czystym stanem. To podejście izoluje awarię do pojedynczej partii dokumentów, jednocześnie zachowując dostępność usługi dla innych klientów, zapewniając, że uszkodzona pamięć nigdy nie jest dereferencjonowana przez logikę aplikacji. Rezultatem był wskaźnik 99,99% uptime podczas agresywnego testowania fuzz, z automatycznym odzyskiwaniem kończącym się w mniej niż 50 milisekund, znacznie przekraczającym surowe wymagania SLA dotyczące opóźnienia przetwarzania dokumentów.
Dlaczego RwLock również implementuje zatrucie, podczas gdy standardowa biblioteka Mutex jest generalnie preferowana do ochrony prostych typów Copy?
RwLock chroni złożone inwarianty identyczne jak Mutex, ale jego zatrucie rozszerza się zarówno na strażników odczytu, jak i zapisu, ponieważ panikujący pisarz mógłby uszkodzić stan obserwowany przez późniejszych czytelników. Jednak dla prostych typów Copy, takich jak liczby całkowite, Mutex jest preferowany w porównaniu do RwLock, nie dlatego, że różnice w zatruciu — oba zatrucie identycznie — ale dlatego, że Mutex oferuje mniejsze obciążenie w przypadku braku konfliktu w dostępie. Ponadto, zatrucie jest semantycznie nieistotne dla typów Copy, ponieważ nie mogą one wykazywać naruszeń wewnętrznych inwariantów; panika podczas przypisania po prostu pozostawia starą wartość nietkniętą, co czyni odzyskiwanie trywialnym poprzez nadpisanie bez złożonej logiki walidacji.
Jak std::sync::PoisonError::new różni się od wewnętrznego mechanizmu zatrucia i dlaczego niebezpiecznie jest ręcznie konstruować zatruty strażnik dla nieotruwanego Mutex?
PoisonError::new jest publicznym konstruktorem pozwalającym na ręczne tworzenie wariantu błędu, ale nie modyfikuje rzeczywiście wewnętrznej flagi zatrucia podstawowego Mutex; jedynie owija strażnika w typ błędu dla zgodności z API. Ręczne wstrzykiwanie takiego błędu do przepływu aplikacji omija bezpieczeństwo wymuszone przez kompilator, które wymaga jawnego zarządzania stanem zatrucia, potencjalnie pozwalając na dostęp do danych, które inny wątek jednocześnie próbuje odtworzyć. Tworzy to wyścig danych, jeśli ręczna konstrukcja pokrywa się z rzeczywistą logiką zatrucia, gdyż dwa wątki mogą jednocześnie uważać, że mają wyłączną własność praw do odzyskiwania, prowadząc do scenariuszy podwójnego zwolnienia lub użycia po zwolnieniu podczas resetowania stanu.
Czy zatrucie można bezpiecznie "wyczyścić" bez niszczenia Mutex, a co implicuje PoisonError::into_inner() o gwarancjach bezpieczeństwa pamięci?
Chociaż into_inner() wyodrębnia strażnika i odrzuca owijkę błędu, nie czyści wewnętrznego stanu zatrucia Mutex; blokada pozostaje na stałe zatruta dla wszystkich przyszłych nabyć, dopóki Mutex nie zostanie usunięty i odtworzony. To implicuje, że wszelkie dane uzyskiwane przez into_inner() muszą być traktowane jako potencjalnie naruszające inwarianty ich typów, co wymaga pełnej ręcznej walidacji lub rekonstrukcji chronionego stanu przed ponownym użyciem. Kandydaci często pomijają, że into_inner() nie zapewnia automatycznego odzyskiwania; po prostu wymienia bezpieczeństwo wariantu Err na surowy dostęp do potencjalnie niebezpiecznej pamięci, wymagając logiki unsafe, aby ponownie ustalić inwarianty przed uznaniem danych za bezpieczne do ogólnego użycia.