Przed Swift 4 język zezwalał na nakładające się dostęp do pamięci, polegając na dyscyplinie programisty w celu zapobiegania undefined behavior. Apple wprowadziło Prawo Wyłączności jako podstawowe gwarancje bezpieczeństwa pamięci, nakazując, że każda zmienna może być dostępna przez wielu czytelników lub jednego pisarza, ale nigdy jednocześnie przez obie te grupy.
Główny problem powstaje, gdy dwa zmienne referencyjne mogą być modyfikowane - lub jedna zmienna modyfikowalna i jedna niemodyfikowalna - mają jednoczesny dostęp do tej samej lokalizacji w pamięci. Takie sytuacje typowo manifestują się w przypadku parametrów inout, metod modyfikujących lub nakładających się uchwytów zamknięcia, co prowadzi do wyścigów danych, niespójnych zrzutów lub uszkodzenia sterty.
Swift wdraża hybrydową strategię egzekwowania. Kompilator przeprowadza analizę statyczną def-use, aby odrzucić oczywiste naruszenia w czasie kompilacji, takie jak przekazywanie tej samej zmiennej jako dwóch argumentów inout do funkcji. W bardziej złożonych scenariuszach z uchwytami zamknięcia, operacjami długotrwałymi lub aliasowaniem zależnym od czasu wykonywania, kompilator wprowadza dynamiczne instrumentowanie. To śledzenie w czasie wykonywania utrzymuje zestaw dostępu dla każdego wątku; gdy wykryty zostanie nakładający się dostęp do modyfikowalnego obiektu, program zatrzymuje się natychmiast, zamiast wykazywać undefined behavior.
struct SignalProcessor { var waveform: [Float] mutating func amplify(by factor: Float, using buffer: (inout [Float]) -> Void) { buffer(&waveform) } } var processor = SignalProcessor(waveform: [0.1, 0.2, 0.3]) // Pułapka w czasie wykonywania: nakładający się dostęp do 'processor.waveform' processor.amplify(by: 2.0) { wave in processor.waveform = [1.0] // Próba zapisu podczas gdy 'wave' trzyma odniesienie inout wave[0] = 0.5 }
Aplikacja do syntezowania dźwięku w czasie rzeczywistym dla iOS renderowała bufor audio na wysoko priorytetowej DispatchQueue, podczas gdy wątek UI wizualizował dane falowe. Nieregularne awarie występowały podczas szybkich dostosowań parametrów, z dziennikami awarii wskazującymi na uszkodzenie sterty w operacjach UnsafeMutablePointer.
Zespół deweloperski rozważył trzy różne rozwiązania architektoniczne.
Implementacja korzystająca z synchronizacji os_unfair_lock. Chronili wspólną strukturę AudioBuffer lekkim blokadą spinującą. Chociaż to zapobiegało wyścigom danych, kontencja blokady między callbackiem audio (który nigdy nie może blokować) a wątkiem UI powodowała zanik dźwięku. Dodatkowo wystąpiła inwersja priorytetów, gdy UI trzymał blokadę, podczas gdy wątek w czasie rzeczywistym czekał, naruszając surowe wymagania czasowe Core Audio.
Implementacja korzystająca z kopiowania wartości niemodyfikowalnych. Przekształcili AudioBuffer do struct i przesyłali kopie do wątku UI w każdej klatce. To eliminowało potrzebę synchronizacji, ale wprowadzało nieakceptowalną latencję. Kopiowanie buforów 1024-próbkowych przy 60Hz przydzielało megabajty tymczasowej pamięci na sekundę, co inicjowało ruch ARC Swift oraz presję alokatora Core Foundation, co prowadziło do słyszalnych zakłóceń.
Implementacja wykorzystująca ekskluzywność Swift z rygorystycznym zakresem. Wyeliminowali współdzielony stan modyfikowalny, upewniając się, że callback audio miał wyłączny dostęp do bufora tylko w dobrze zdefiniowanym zakresie, używając parametrów inout do przetwarzania etapów. UI otrzymywał tylko do odczytu zrzuty za pomocą akcesoriów nonmutating. To rozwiązanie zostało wybrane, ponieważ wykorzystywało statyczne kontrole wyłączności Swift, aby udowodnić bezpieczeństwo, całkowicie eliminując narzuty synchronizacji w czasie wykonywania, a tym samym zapobiegając jakiejkolwiek możliwości nakładającej się modyfikacji.
Refaktoryzacja wyeliminowała wszystkie awarie z uszkodzeniami sterty. Użycie CPU spadło o 40% dzięki usunięciu prymitywów blokujących i obiegu alokacji pamięci, a potok audio osiągnął działanie bez zakłóceń pod dużym obciążeniem.
Dlaczego egzekwowanie wyłączności pozwala na jednoczesny dostęp do odczytu, ale łapie w przypadku nakładającego się odczytu-zapisu, i jak Swift rozróżnia je na poziomie kodu maszynowego?
Kandydaci często mylą wyłączność z ogólnym bezpieczeństwem wątków. Swift zezwala na wiele jednoczesnych dostępów tylko do odczytu, ponieważ nie mogą one modyfikować stanu, ale każdy zapis wymaga wyłączności. Na poziomie kodu maszynowego kompilator pomija śledzenie w czasie wykonywania dla dostępu tylko do odczytu (chyba że skompilowane z użyciem narzędzia thread sanitizer), podczas gdy zapisy wywołują wywołania w czasie wykonywania swift_beginAccess, które rejestrują lokalizację pamięci w zestawie dostępu lokalnym dla wątku. Czas wykonywania używa systemu flag (read vs modify) do określenia konfliktów, pozwalając na współbieżne odczyty, ale zatrzymując, gdy flaga modify napotyka istniejący dostęp jakiegokolwiek rodzaju.
Jak Swift radzi sobie z naruszeniami wyłączności, które rozciągają się przez punkty zawieszenia w kodzie async/await?
Wielu kandydatów zakłada, że async/await automatycznie rozwiązuje problemy z wyłącznością. Jednak Swift traktuje await jako potencjalną granicę dostępu. Jeśli zadanie posiada odniesienie inout do zmiennej i napotyka na await, kompilator musi albo udowodnić, że dostęp kończy się przed zawieszeniem, albo wydłużyć go przez zawirowanie. Czas wykonywania śledzi te dostępy per-task. Jeśli inne zadanie spróbuje uzyskać dostęp do tej samej pamięci, podczas gdy pierwsze jest zawieszone trzymając wyłączne prawa, czas wykonywania zatrzymuje się. Deweloperzy muszą unikać trzymania odniesień inout przez granice await lub inkapsulować stan w Actors, aby zapewnić odpowiednią izolację w czasie zawieszenia.
Pod jaką konkretną flagą optymalizacji kompilatora jest dezaktywowane sprawdzanie wyłączności w czasie wykonywania i jakie katastrofalne tryby awarii się z tym wiążą?
Kandydaci często wierzą, że wyłączność jest niezmienna. Swift oferuje tryb kompilacji -Ounchecked, który dezaktywuje wszystkie kontrole wyłączności w czasie wykonywania dla kodu krytycznego pod względem wydajności. W tej konfiguracji, utajone naruszenia wyłączności - takie jak nakładające się modyfikacje inout z równoległych zamknięć - powodują ciche uszkodzenia sterty zamiast deterministycznych pułapek. Może to skutkować uszkodzoną pamięcią String, gdzie pola długości przestają pasować do zawartości bufora, uszkodzeniem metadanych Array, prowadzącym do dostępu do pamięci poza granicami, lub wykonywaniem dowolnego kodu, jeśli uszkodzone wskaźniki zostaną później dereferencjonowane. Ta flaga powinna być używana tylko wtedy, gdy formalna weryfikacja lub wyczerpująca analiza statyczna udowodniła brak nakładających się dostępów.