Swift umożliwia modyfikację in-place dzięki kombinacji konwencji przekazywania parametrów inout oraz funkcji uruchomieniowej isUniquelyReferenced. Gdy wywoływana jest metoda mutująca, kompilator przekształca wywołanie w parametr inout na poziomie SIL, przyznając metodzie wyłączny dostęp do pamięci wartości na czas wywołania. Przed modyfikacją jakiejkolwiek pamięci typu heap udostępnionej przez odniesienie do klasy, czas wykonywania sprawdza, czy liczba odniesień wynosi dokładnie jeden, używając isUniquelyReferenced; jeśli tak, można przystąpić do bezpośredniej modyfikacji, w przeciwnym razie tworzona jest kopia zabezpieczająca. Prawo Wyłączności, egzekwowane za pomocą analizy statycznej w czasie kompilacji i dynamicznego instrumentowania podczas uruchamiania, zapewnia, że żaden inny wątek lub ścieżka wykonania nie może uzyskać dostępu do wartości w krytycznym oknie sprawdzania modyfikacji, zapobiegając warunkom wyścigu przy zachowaniu semantyki wartości bez zbędnych alokacji.
Wyobraź sobie rozwój wydajnej aplikacji do edycji zdjęć, która przetwarza surowe dane obrazów RAW przy użyciu struktury ImageBuffer otaczającej 50-megapikselową tablicę bajtów. Każde zastosowanie filtru — rozmycie, wyostrzanie lub korekcja koloru — wymaga modyfikacji milionów pikseli, a użytkownicy oczekują podglądów w czasie rzeczywistym przy dziesięciu lub więcej sekwencyjnych poprawkach bez opóźnień trwających wiele sekund ani awarii pamięci.
Jednym z potencjalnych rozwiązań była konwersja ImageBuffer z struct na class, aby wyeliminować narzut kopiowania poprzez wspólny stan mutowalny. Choć podejście to zapobiegło fizycznej duplikacji pamięci podczas łańcuchów filtrów, wprowadziło poważne zagrożenia dla bezpieczeństwa wątków, gdy wątki renderujące w tle uzyskiwały jednoczesny dostęp do buforów, a także naruszało semantykę wartości, powodując, że filtry niezamierzenie modyfikowały oryginalne dane obrazów współdzielone w stosie historii cofnij/ponów.
Inne rozważane podejście to ręczne głębokie kopiowanie całego bufora pikseli przed każdą operacją filtru, aby zapewnić pełną izolację między etapami. Chociaż strategia ta zachowywała doskonałą semantykę wartości i bezpieczeństwo wątków, powodowała katastrofalne spowolnienie wydajności — przetwarzanie pojedynczego obrazu o wysokiej rozdzielczości przez dwanaście filtrów wymagało kopiowania setek megabajtów pamięci dwanaście razy, co skutkowało opóźnieniem trwającym wiele sekund i szczytami pamięci przekraczającymi fizyczne limity urządzenia.
Wybrane rozwiązanie wdrożono przy użyciu semantyki Copy-on-Write, korzystając z prywatnej klasy zaplecza Storage (końcowa klasa Swift) referencjonowanej przez strukturę ImageBuffer. Każda metoda mutująca filtru najpierw wywoływała isUniquelyReferenced na instancji zaplecza; podczas przetwarzania sekwencyjnego pierwsza modyfikacja wyzwalała kopiowanie, podczas gdy kolejne modyfikacje na tej samej instancji bufora działały na miejscu bez alokacji. Ten projekt zachował semantykę wartości Swift — umożliwiając bezpieczne operacje cofania/ponawiania za pomocą efektywnego kopiowania struct — przy jednoczesnym zachowaniu interaktywnej wydajności poprzez unikanie zbędnej duplikacji pamięci podczas łańcuchów filtrów.
Efektem był płynny proces edycji, w którym użytkownicy mogli zastosować dwanaście sekwencyjnych filtrów do obrazów o wysokiej rozdzielczości z czasem reakcji poniżej 100 milisekund i stabilnym zużyciem pamięci poniżej 200 MB, w porównaniu do wcześniejszych szczytów pamięci sięgających wielu gigabajtów i zastoju aplikacji spowodowanych nadmiernym kopiowaniem.
Dlaczego isUniquelyReferenced zwraca false dla obiektów Objective-C, nawet gdy wydaje się, że tylko jedna zmienna Swift trzyma odniesienie?
Obiekty Objective-C mogą zawierać "dodatkowe" odniesienia niewidoczne dla mechanizmu liczenia odniesień w Swift, takie jak odniesienia nieprzechowywane pochodzące z obiektów powiązanych, rejestracje NSNotificationCenter lub obserwatorzy KVO. Funkcja isUniquelyReferenced sprawdza, czy wartość silnego licznika odniesień wynosi jeden i czy obiekt jest "czystym obiektem native Swift"; dla podklas NSObject czas uruchamiania Objective-C może zatrzymać obiekt bez aktualizacji licznika w sposób, który Swift może zaobserwować, lub obiekt może być nieśmiertelny (singleton). W konsekwencji, Swift dostarcza isUniquelyReferencedNonObjC, aby wyraźnie obsłużyć to ograniczenie, chociaż programiści powinni ogólnie upewnić się, że zaplecza COW są czystymi klasami Swift, aby zapewnić dokładne wykrywanie unikalności i uniknąć cichych regresji wydajności, gdy kopiowanie następuje niepotrzebnie.
Jak Prawo Wyłączności zapobiega warunkom wyścigu podczas sprawdzania unikalności w kontekście współbieżnym?
Prawo Wyłączności nakazuje, że każdy dostęp do wartości mutowalnej musi być wyłączny w czasie tego dostępu, co jest egzekwowane przez kombinację analizy statycznej w czasie kompilacji i dynamicznego śledzenia uruchomieniowego przy użyciu instrumentacji sprawdzania wyłączności w Swift. Gdy metoda mutująca przeprowadza sprawdzenie isUniquelyReferenced, czas wykonywania już ustanowił rekord wyłącznego dostępu do tej lokalizacji pamięci; jeśli inny wątek próbuje odczytać lub zapisać wartość w tym oknie, naruszenie wyłączności zostaje wykryte natychmiast — albo w czasie kompilacji dla naruszeń statycznych, albo poprzez blokadę w czasie wykonywania dla naruszeń dynamicznych. To zapobiega warunkowi wyścigu "sprawdź-wtedy-działaj", w którym drugi wątek może zwiększyć licznik odniesień między weryfikacją unikalności a rzeczywistą mutacją, co w przeciwnym razie prowadziłoby do dwóch wątków mutujących wspólny bufor jednocześnie, naruszając semantykę wartości i powodując uszkodzenie danych lub awarie.
Dlaczego zaplecze COW musi być zaimplementowane jako klasa, a nie struktura, i jaki tryb błędu występuje, jeśli użyta jest struktura?
Copy-on-Write wymaga wspólnego stanu mutowalnego, aby śledzić, kiedy konieczne jest zabezpieczające kopiowanie; tylko typy odniesień (klasy) zapewniają tożsamość obiektu i wspólne liczenie odniesień we wszystkich kopiach opakowania typu wartości. Jeśli deweloper pomyłkowo wdraża zaplecze jako struct, każde przypisanie nadrzędnego typu wartości tworzy odrębną kopię opakowania zaplecza, co oznacza, że pole licznika odniesień samo jest powielane, a nie współdzielone. W konsekwencji, isUniquelyReferenced zawsze zwraca prawdę dla każdej kopii niezależnie, co prowadzi do błędnych założeń unikalności i przeprowadzenia modyfikacji in-place na buforach, które są logicznie współdzielone, co prowadzi do błędów mutacji między wartościami, gdzie modyfikacja jednej instancji struct niespodziewanie zmienia dane widoczne przez inną, pozornie niezależną zmienną.