Zwracając std::coroutine_handle z await_suspend, umożliwiamy symetryczny transfer, formę gwarantowanej optymalizacji wywołania końcowego (TCO). Gdy await_suspend zwraca void, runtime korutyn musi wrócić do swojego wywołującego przed wznowieniem następnej korutyny, co prowadzi do liniowego wzrostu stosu wywołań w miarę długości łańcucha. Zwracając uchwyt, kompilator emituje bezpośredni skok (jmp instrukcja) do punktu wznowienia docelowej korutyny, ponownie wykorzystując aktualny rekord aktywacji i utrzymując stałą głębokość stosu O(1) niezależnie od długości łańcucha.
struct SymmetricTransfer { std::coroutine_handle<> next; // Optymalizacja wywołania końcowego: brak wzrostu stosu std::coroutine_handle<> await_suspend(std::coroutine_handle<>) { return next; } void await_resume() {} bool await_ready() { return false; } };
Opracowaliśmy silnik przetwarzania dźwięku w czasie rzeczywistym dla profesjonalnego oprogramowania do produkcji muzycznej. System wykorzystywał C++20 korutyny do reprezentacji potoku 500+ efektów przetwarzania sygnału cyfrowego (DSP) (filtry, kompresory, pogłosy) połączonych w łańcuch. Podczas testów obciążeniowych aplikacja zawiesiła się z powodu przepełnienia stosu, gdy ładowano złożone zestawy efektów, mimo że każda pojedyncza korutyna miała minimalny stan lokalny.
Rozwiązanie 1: Zwracanie void w await_suspend z bezpośrednim wznowieniem Początkowa implementacja wykorzystywała void await_suspend(std::coroutine_handle<>) i wewnętrznie wywoływała next.resume(). To podejście oferowało intuicyjny, sekwencyjny przepływ kodu oraz łatwe debugowanie za pomocą standardowych zrzutów stosu. Jednak każde wywołanie resume() zagnieżdżone w logice zawieszenia poprzedniej korutyny zużywało około 16KB na etap, wyczerpując 8MB stosu wątku po zaledwie 500 etapach.
Rozwiązanie 2: Kolejka robocza z asynchronicznym planowaniem Rozważaliśmy zastąpienie bezpośredniego łańcuchowania scentralizowaną kolejką zadań, w której każda korutyna przekazywała następny etap jako element roboczy i natychmiast się zawieszała. To gwarantowało stałe zużycie stosu, przekształcając rekurencję w iterację. Wadą były znaczące pogorszenia wydajności: dynamiczne alokacje dla węzłów kolejki, zniekształcenia pamięci podręcznej z powodu kontencji wątków oraz utrata lokalności pamięci podręcznej między etapami potoku, co naruszało nasze wymagania dotyczące opóźnienia na poziomie sub-milisekund.
Rozwiązanie 3: Symetryczny transfer za pomocą coroutine_handle Przeorganizowaliśmy await_suspend, aby bezpośrednio zwracać std::coroutine_handle następnego etapu. To zasygnalizowało kompilatorowi, aby wykonał TCO, redukując ramki stosu. Rozwiązanie zachowało abstrakcję zerokosztową korutyn, jednocześnie zapewniając O(1) zużycia pamięci. Główne ryzyko dotyczyło zarządzania czasem życia: gdy uchwyt został zwrócony, aktualna korutyna została zawieszona, a dostęp do this lub zmiennych lokalnych po punkcie zwrotu prowadził do niezdefiniowanego zachowania.
Wybrane rozwiązanie i wynik Przyjęliśmy rozwiązanie 3. Po refaktoryzacji potok z powodzeniem przetwarzał 512 kolejnych efektów, używając jedynie 4KB przestrzeni stosu, eliminując awarie i utrzymując deterministyczną wydajność czasu rzeczywistego. Zmiana wymagała starannych przeglądów kodu w celu upewnienia się, że nie istnieje logika po powrocie w await_suspend, ale skutkowała solidną, skalowalną architekturą.
Dlaczego symetryczny transfer wymaga zwrócenia std::coroutine_handle zamiast używania co_await w następnej korutynie wewnątrz await_suspend?
Użycie co_await wewnątrz await_suspend wymagałoby, aby korutyna oczekująca była najpierw całkowicie zawieszona, a następnie wznowiona później, co inherently wiąże się z powrotem do runtime'u i wzrostem stosu. Zwracając uchwyt bezpośrednio, kompilator może traktować wznowienie jako wywołanie końcowe, podczas gdy co_await generuje asymetryczny punkt zawieszenia, który musi zachować ramkę wywołującego, aby wznowić ją później.
Jak symetryczny transfer wpływa na bezpieczeństwo wyjątków, jeśli wznowiona korutyna zgłasza wyjątek przed osiągnięciem swojego końcowego punktu zawieszenia?
Jeśli korutyna, do której dokonano symetrycznego transferu, zgłasza wyjątek, wyjątek teoretycznie rozprzestrzenia się przez ramkę await_suspend, ale ponieważ oryginalna korutyna jest już oznaczona jako zawieszona, jej ramka musi zostać zniszczona podczas rozprzestrzeniania stosu. Wymaga to od kompilatora wygenerowania złożonych tabel obsługi wyjątków, które niszczą promise i przechwycone parametry zawieszonej korutyny. Kandydaci często nie dostrzegają, że niestandardowe alokatory promise_type muszą prawidłowo obsługiwać częściową konstrukcję, aby nie ryzykować błędów podwójnego zniszczenia podczas rozprzestrzeniania wyjątków.
Co uniemożliwia użycie symetrycznego transferu przy implementacji generatora, który zwraca wartości z rekurencyjnej struktury danych?
Generatory polegają na co_yield, aby zwrócić kontrolę do wywołującego, jednocześnie zachowując swój stan. Symetryczny transfer bezwarunkowo przekazuje kontrolę do innej korutyny i nigdy nie wraca do oryginalnego wywołującego, dopóki cały łańcuch się nie zakończy. Dlatego generatory muszą używać asymetrycznego zawieszenia (zwracając void lub true z await_suspend), aby pozwolić konsumentowi na otrzymanie zwróconej wartości i ewentualne wznowienie generatora później, zamiast wymuszać nieodwracalny transfer do innej korutyny.