Odpowiedź na pytanie
Model współbieżności Swifta został znacznie wzmocniony w wersji 6.0, wprowadzając surowe wymagania dotyczące izolacji danych, które rozciągają się na granice modułów. Kiedy moduł skompilowany ze ścisłym sprawdzaniem współbieżności wywołuje stary moduł oznaczony jako @preconcurrency, kompilator nie może polegać tylko na analizie statycznej, aby zagwarantować bezpieczeństwo, ponieważ implementacja wywoływanego może pochodzić z okresu przed gwarancjami izolacji aktora. Aby wypełnić tę lukę, Swift osadza wymagania dotyczące izolacji jako metadane w informacji o typie funkcji i tabelach świadków, zachowując stabilność ABI poprzez niezmienianie konwencji wywołania ani manglowania symboli. W czasie wykonywania wygenerowany kod wykonuje dynamiczne sprawdzenie za pomocą wbudowanego swift_task_isCurrentExecutor, aby zweryfikować, że bieżące zadanie jest wykonywane na wymaganego globalnego aktora’s szeregowego wykonawcy przed kontynuowaniem; jeśli sprawdzenie nie powiedzie się, zadanie zostaje asynchronicznie pozbawione do odpowiedniego wykonawcy lub generowane jest diagnostyczne awarie, w zależności od konfiguracji kompilacji.
Sytuacja z życia
Zespół technologii finansowych utrzymywał stary zestaw SDK do analizy (Moduł B) napisany w Swifcie 5.9, który wykonywał ciężkie obliczenia statystyczne w wątkach tła, ale od czasu do czasu aktualizował interfejs użytkownika poprzez wywołania zwrotne. Kiedy przyjęli Swifta 6 w swojej nowej aplikacji bankowej dla konsumentów (Moduł A), musieli zapewnić, że wszystkie aktualizacje interfejsu użytkownika miały miejsce na MainActor bez natychmiastowego przepisywania całego SDK. Rozważali trzy podejścia w celu rozwiązania problemu granicy izolacji.
Pierwsza opcja polegała na synchronizacji przepisania SDK w celu przyjęcia aktora Swifta 6 i typów Sendable w całym zakresie. Chociaż zapewniłoby to bezpieczeństwo na etapie kompilacji i zerowy narzut czasowy, koszt inżynieryjny byłby zbyt wysoki — szacowany na trzy miesiące — i wprowadzałby wysokie ryzyko regresji w krytycznej logice obliczeniowej. Druga opcja polegała na ręcznym owijaniu każdego wywołania zwrotnego SDK w DispatchQueue.main.async w punktach wywołania w Moduł A. To podejście było wyraźne i nie wymagało zmian w SDK, ale produkowało kruchy, rozproszony kod, który łatwo było przeoczyć, co prowadziło do potencjalnych konfliktów danych, gdy nowi programiści dodawali funkcje. Trzecia opcja wykorzystywała adnotacje @preconcurrency w publicznym interfejsie SDK w połączeniu z wymaganiami izolacji MainActor.
Zespół wybrał trzecią opcję, adnotując wywołania zwrotne dziedziczone z @preconcurrency @MainActor. To pozwoliło Moduł A na wywoływanie tych metod z zapewnieniem, że Swift uruchomi weryfikację kontekstu wykonawcy dynamicznie w trakcie okresu przejściowego. Kiedy dochodziło do naruszeń — na przykład wątek tła próbował wywołać wywołanie zwrotne interfejsu użytkownika — aplikacja natychmiast zawieszała się w wersjach debug z wyraźnymi informacjami diagnostycznymi, umożliwiając programistom identyfikację i stopniowe naprawianie założeń dotyczących wątków. Gdy SDK zostało całkowicie przeniesione na surową współbieżność, usunęli @preconcurrency, aby egzekwować wyłącznie statyczną izolację, skutkując bazą kodu bez sprawdzania izolacji w czasie wykonywania i gwarantującą bezpieczeństwo wątków.
Co często umyka kandydatom
Jak @preconcurrency wpływa na nazwę zmanglowanego symbolu funkcji w ABI i dlaczego to ma znaczenie dla dynamicznego linkowania?
@preconcurrency nie zmienia zmanglowanej nazwy symbolu ani niskopoziomowej konwencji wywołania funkcji, ponieważ wymagania dotyczące izolacji są kodowane w metadanych typu i tabelach świadków, a nie w samym symbolu. Ten projekt jest kluczowy dla stabilności ABI, ponieważ pozwala autorom bibliotek na dodawanie izolacji aktora do istniejących publicznych API bez łamania zgodności binarnej z wcześniej skompilowanymi klientami. Dynamiczne kontrole są wstrzykiwane w miejscu wywołania lub punkcie wejścia przez kompilator w oparciu o metadane, co zapewnia, że starsze binaria mogą automatycznie łączyć się z nowszymi, świadomymi izolacji bibliotekami bezproblemowo.
Jaka jest różnica między deklarowaniem wspólnej instancji globalnego aktora jako let a var, i jak to wpływa na unikalność wykonawcy?
Protokół GlobalActor wymaga statycznej właściwości shared, która zwraca podstawową instancję aktora, a ta właściwość musi być zadeklarowana jako stała let, aby zapewnić unikalny, procesowo-spójny, szeregowy wykonawca. Jeśli shared byłby zmienną var, to teoretycznie wykonawca mógłby być zamieniany w czasie wykonywania, co naruszyłoby fundamentalną zasadę, że globalny aktor zapewnia jedną szeregową kolejkę dla wszystkich izolowanych operacji, co potencjalnie prowadziłoby do konfliktów danych i łamało granice izolacji. Kompilator Swifta egzekwuje to, wymagając, aby shared była statyczną, niezmienną właściwością, co zapewnia, że swift_task_isCurrentExecutor zawsze porównuje z unikalnym, stałym obiektem wykonawcy.
Kiedy funkcja jest izolowana w globalnym aktorze, dlaczego kompilator czasami emituje skok do wykonawcy, nawet gdy jest wywoływana z tego samego aktora, i jak modyfikator parametru isolated optymalizuje to?
Kompilator emituje skok do wykonawcy — lub przynajmniej weryfikację w czasie wykonywania — gdy nie może statycznie dowieść, że wywołujący już wykonuje się na wykonawcy docelowego globalnego aktora, co zwykle występuje między granicami modułów lub przy wywoływaniu przez typy egzystencjalne, gdzie informacje o izolacji są usuwane. To konserwatywne podejście zapewnia bezpieczeństwo, ale wiąże się z narzutem synchronizacji. Programiści mogą to optymalizować, używając modyfikatora parametru isolated (np. func process(isolation: isolated MainActor = #isolation)), co wyraźnie przekazuje kontekst izolacji wywołującego jako argument; to pozwala kompilatorowi na pominięcie sprawdzenia w czasie wykonywania i skoku, gdy wywołujący dowodzi, że znajduje się na tym samym wykonawcy, co redukuje wywołanie do bezpośredniego wywołania funkcji bez kosztów przełączania kontekstu.