Se préparer pour C ++ 20. Étude de cas réelle Coroutines TS

En C ++ 20, l'opportunité de travailler avec des coroutines prêtes à l'emploi est sur le point d'apparaître. Ce sujet est proche et intéressant pour nous chez Yandex.Taxi (pour nos propres besoins, nous développons un framework asynchrone). Par conséquent, aujourd'hui, nous allons montrer aux lecteurs de Habr en utilisant un exemple réel comment travailler avec des coroutines sans pile C ++.

À titre d'exemple, prenons quelque chose de simple: sans travailler avec des interfaces réseau asynchrones, des minuteries asynchrones, constituées d'une seule fonction. Par exemple, essayons de réaliser et de réécrire cette "nouille" à partir des rappels:

void FuncToDealWith() { InCurrentThread(); writerQueue.PushTask([=]() { InWriterThread1(); const auto finally = [=]() { InWriterThread2(); ShutdownAll(); }; if (NeedNetwork()) { networkQueue.PushTask([=](){ auto v = InNetworkThread(); if (v) { UIQueue.PushTask([=](){ InUIThread(); writerQueue.PushTask(finally); }); } else { writerQueue.PushTask(finally); } }); } else { finally(); } }); } 

Présentation

Les coroutines ou coroutines sont la capacité d'empêcher une fonction de s'exécuter dans un emplacement prédéterminé; passer quelque part l'état entier de la fonction arrêtée avec les variables locales; exécutez la fonction du même endroit où nous l'avons arrêtée.
Il existe plusieurs saveurs de coroutines: empilables et empilables. Nous en reparlerons plus tard.

Énoncé du problème

Nous avons plusieurs files d'attente de tâches. Chaque tâche contient certaines tâches: il y a une file d'attente pour dessiner des graphiques, il y a une file d'attente pour les interactions réseau et il y a une file d'attente pour travailler avec un disque. Toutes les files d'attente sont des instances de la classe WorkQueue qui ont la méthode void PushTask (tâche std :: function <void ()>);. Les files d'attente vivent plus longtemps que toutes les tâches qui y sont placées (la situation selon laquelle nous avons détruit une file d'attente lorsqu'elle contient des tâches en suspens ne devrait pas se produire).

La fonction FuncToDealWith () de l'exemple exécute une logique dans différentes files d'attente et, selon les résultats de l'exécution, place une nouvelle tâche dans la file d'attente.

Nous réécrivons les «nouilles» des rappels sous la forme d'un pseudo-code linéaire, marquant dans quelle file d'attente le code sous-jacent doit être exécuté:

 void CoroToDealWith() { InCurrentThread(); // =>   writerQueue InWriterThread1(); if (NeedNetwork()) { // =>   networkQueue auto v = InNetworkThread(); if (v) { // =>   UIQueue InUIThread(); } } // =>   writerQueue InWriterThread2(); ShutdownAll(); } 

Environ ce résultat que je veux atteindre.

Il y a des limitations:

• Les interfaces de file d'attente ne peuvent pas être modifiées - elles sont utilisées dans d'autres parties de l'application par des développeurs tiers. Vous ne pouvez pas casser le code développeur ou ajouter de nouvelles instances de file d'attente.
• Vous ne pouvez pas modifier la façon dont vous utilisez la fonction FuncToDealWith. Vous pouvez seulement changer son nom, mais vous ne pouvez pas lui faire retourner des objets que l'utilisateur doit garder à la maison.
• Le code résultant doit être aussi productif que l'original (ou même plus productif).

Solution

Réécrire la fonction FuncToDealWith

Dans Coroutines TS, le réglage de la coroutine se fait en définissant le type de la valeur de retour de la fonction. Si le type satisfait certaines exigences, vous pouvez utiliser les nouveaux mots clés co_await / co_return / co_yield dans le corps de la fonction. Dans cet exemple, pour basculer entre les files d'attente, nous utiliserons co_yield:

 CoroTask CoroToDealWith() { InCurrentThread(); co_yield writerQueue; InWriterThread1(); if (NeedNetwork()) { co_yield networkQueue; auto v = InNetworkThread(); if (v) { co_yield UIQueue; InUIThread(); } } co_yield writerQueue; InWriterThread2(); ShutdownAll(); } 

Il s'est avéré très similaire au pseudocode de la dernière section. Toute la «magie» pour travailler avec des coroutines est cachée dans la classe CoroTask.

CoroTask

Dans le cas le plus simple (dans notre) cas, le contenu de la classe "tuner" de la coroutine est constitué d'un seul alias:

 #include <experimental/coroutine> struct CoroTask { using promise_type = PromiseType; }; 

promise_type est un type de données que nous devons écrire nous-mêmes. Il contient une logique qui décrit:

• que faire à la sortie de coroutine
• que faire lorsque vous entrez pour la première fois dans la corutine
• qui libère des ressources
• que faire avec les exceptions sortant de la coroutine
• Comment créer un objet CoroTask
• que faire si à l'intérieur des corutines appelées co_yield

L'alias promise_type doit être appelé de cette façon. Si vous changez le nom d'alias en quelque chose d'autre, le compilateur jurera et dira que vous avez mal orthographié CoroTask. Le nom CoroTask peut être modifié comme vous le souhaitez.

PromiseType

Arriver à la partie amusante. Nous décrivons le comportement de la corutine:

 class WorkQueue; // forward declaration class PromiseType { public: //      `co_return;`     , ... void return_void() const { /* ...    :) */ } //        ,  CoroTask, ... auto initial_suspend() const { // ...       . return std::experimental::suspend_never{}; } //      - , ... auto final_suspend() const { // ...        //      . return std::experimental::suspend_never{}; } //     , ... void unhandled_exception() const { // ...   (  ). std::terminate(); } //    CoroTask,    , ... auto get_return_object() const { // ...  CoroTask. return CoroTask{}; } //     co_yield, ... auto yield_value(WorkQueue& wq) const; // ... <  > }; 

Dans le code ci-dessus, vous pouvez remarquer le type de données std :: experimental :: suspend_never. Il s'agit d'un type de données spécial qui indique que la corutine n'a pas besoin d'être arrêtée. Il y a aussi son contraire - le type std :: experimental :: suspend_always, qui vous dit d'arrêter la corutine. Ces types sont les soi-disant attendables. Si vous êtes intéressé par leur structure interne, ne vous inquiétez pas, nous écrirons bientôt nos Awaitables.

L'endroit le plus simple dans le code ci-dessus est final_suspend (). La fonction a des effets inattendus. Donc, si nous n'arrêtons pas l'exécution dans cette fonction, les ressources allouées à la coroutine par le compilateur nettoieront le compilateur pour nous. Mais si dans cette fonction nous arrêtons l'exécution de coroutine (par exemple, en retournant std :: experimental :: suspend_always {}), alors vous devrez libérer manuellement des ressources de quelque part à l'extérieur: vous devrez enregistrer un pointeur intelligent pour coroutiner quelque part et l'appeler explicitement détruire (). Heureusement, cela n'est pas nécessaire pour notre exemple.

INCORRECT PromiseType :: yield_value

Il semble que l'écriture de PromiseType :: yield_value soit assez simple. Nous avons une ligne; coroutine, qui doit être suspendu et à ce tour mettre:

 auto PromiseType::yield_value(WorkQueue& wq) { //        std::experimental::coroutine_handle<> this_coro = std::experimental::coroutine_handle<>::from_promise(*this); //    .  this_coro  operator(),    // wq      .   , //     ,  operator(),  //   . wq.PushTask(this_coro); //     . return std::experimental::suspend_always{}; } 

Et ici, nous sommes confrontés à un problème très important et difficile à détecter. Le fait est que nous mettons d'abord la coroutine dans la file d'attente et que nous la suspendons ensuite. Il peut arriver que la coroutine soit supprimée de la file d'attente et commence à être exécutée avant même de la suspendre dans le thread actuel. Cela entraînera une condition de concurrence, un comportement indéfini et des erreurs d'exécution complètement folles.

Correct PromiseType :: yield_value

Donc, nous devons d'abord arrêter la corutine et ensuite l'ajouter à la file d'attente. Pour ce faire, nous allons écrire notre Awaitable et l'appeler schedule_for_execution:

 auto PromiseType::yield_value(WorkQueue& wq) { struct schedule_for_execution { WorkQueue& wq; constexpr bool await_ready() const noexcept { return false; } void await_suspend(std::experimental::coroutine_handle<> this_coro) const { wq.PushTask(this_coro); } constexpr void await_resume() const noexcept {} }; return schedule_for_execution{wq}; } 

Les classes std :: experimental :: suspend_always, std :: experimental :: suspend_never, schedule_for_execution et autres Awaitables devraient contenir 3 fonctions. wait_ready est appelé pour vérifier si la coroutine doit être arrêtée. wait_suspend est appelé après l'arrêt du programme, le handle de la coroutine arrêtée lui est transmis. wait_resume est appelé lorsque l'exécution de la coroutine reprend.

Terminé

Vous pouvez compiler, exécuter l'exemple en ligne et expérimenter de toutes les manières .

Feuille de triche

CoroTask est une classe qui ajuste le comportement d'une coroutine. Dans les cas plus complexes, il vous permet de communiquer avec une coroutine arrêtée et de prendre toutes les données de celle-ci.

CoroTask :: promise_type décrit comment et quand les coroutines s'arrêtent, comment libérer des ressources et comment construire CoroTask.

Les fichiers attendus (std :: experimental :: suspend_always, std :: experimental :: suspend_never, schedule_for_execution et autres) indiquent au compilateur quoi faire avec la coroutine à un point spécifique (si arrêter la corutine, quoi faire avec la corutine arrêtée et quoi faire lorsque la corutine se réveille) .

Optimisations

Il y a une faille dans notre PromiseType. Même si nous sommes actuellement en cours d'exécution dans la file d'attente de tâches correcte, appeler co_yield suspendra toujours la coroutine et la replacera dans la même file d'attente de tâches. Il serait beaucoup plus optimal de ne pas arrêter l'exécution de la coroutine, mais de poursuivre immédiatement l'exécution.

Corrigeons cette faille. Pour ce faire, ajoutez un champ privé à PromiseType:

 WorkQueue* current_queue_ = nullptr; 

Dans celui-ci, nous tiendrons un pointeur sur la file d'attente dans laquelle nous sommes actuellement en cours d'exécution.

Ensuite, ajustez PromiseType :: yield_value:

 auto PromiseType::yield_value(WorkQueue& wq) { struct schedule_for_execution { const bool do_resume; WorkQueue& wq; constexpr bool await_ready() const noexcept { return do_resume; } void await_suspend(std::experimental::coroutine_handle<> this_coro) const { wq.PushTask(this_coro); } constexpr void await_resume() const noexcept {} }; const bool do_not_suspend = (current_queue_ == &wq); current_queue_ = &wq; return schedule_for_execution{do_not_suspend, wq}; } 

Ici, nous avons modifié Schedule_for_execution :: Wait_ready (). Maintenant, cette fonction indique au compilateur que la coroutine n'a pas besoin d'être suspendue si la file d'attente de tâches actuelle correspond à celle sur laquelle nous essayons de démarrer.

C'est fait. Vous pouvez expérimenter de toutes les manières .

À propos des performances

Dans l'exemple d'origine, à chaque appel à WorkQueue :: PushTask (std :: function <void ()> f), nous avons créé une instance de la classe std :: function <void ()> à partir du lambda. Dans le code réel, ces lambdas sont souvent de taille assez importante, c'est pourquoi std :: function <void ()> est obligé d'allouer dynamiquement de la mémoire pour stocker les lambdas.

Dans l'exemple coroutine, nous créons des instances de std :: function <void ()> à partir de std :: experimental :: coroutine_handle <>. La taille de std :: experimental :: coroutine_handle <> dépend de l'implémentation, mais la plupart des implémentations essaient de garder sa taille au minimum. Donc, sur clang, sa taille est égale à sizeof (void *). Lors de la construction de std :: function <void ()>, l'allocation dynamique ne se produit pas à partir de petits objets.
Total - avec Coroutines, nous nous sommes débarrassés de plusieurs allocations dynamiques inutiles.

Mais! Souvent, le compilateur ne peut pas simplement enregistrer toute la coroutine sur la pile. De ce fait, une allocation dynamique supplémentaire est possible lors de la saisie de CoroToDealWith.

Stackless vs stackful

Nous venons de travailler avec les coroutines Stackless, qui nécessitent le support du compilateur pour fonctionner. Il existe également des Coroutines empilables qui peuvent être implémentées entièrement au niveau de la bibliothèque.

Les premiers permettent une allocation de mémoire plus économique, potentiellement ils sont mieux optimisés par le compilateur. Les seconds sont plus faciles à implémenter dans les projets existants, car ils nécessitent moins de modifications de code. Cependant, dans cet exemple, vous ne pouvez pas sentir la différence, des exemples plus compliqués sont nécessaires.

Résumé

Nous avons examiné l'exemple de base et obtenu une classe universelle CoroTask, qui peut être utilisée pour créer d'autres coroutines.

Le code avec lui devient plus lisible et légèrement plus productif qu'avec l'approche naïve:

Était	Avec des coroutines
void FuncToDealWith() { InCurrentThread(); writerQueue.PushTask([=]() { InWriterThread1(); const auto fin = [=]() { InWriterThread2(); ShutdownAll(); }; if (NeedNetwork()) { networkQueue.PushTask([=](){ auto v = InNetThread(); if (v) { UIQueue.PushTask([=](){ InUIThread(); writerQueue.PushTask(fin); }); } else { writerQueue.PushTask(fin); } }); } else { fin(); } }); }	CoroTask CoroToDealWith() { InCurrentThread(); co_yield writerQueue; InWriterThread1(); if (NeedNetwork()) { co_yield networkQueue; auto v = InNetThread(); if (v) { co_yield UIQueue; InUIThread(); } } co_yield writerQueue; InWriterThread2(); ShutdownAll(); }

Par dessus bord, il y a eu des moments:

• comment appeler une autre coroutine de la corutine et attendre sa fin
• quels trucs utiles vous pouvez entasser dans CoroTask
• un exemple qui fait la différence entre Stackless et Stackful

Autre

Si vous souhaitez en savoir plus sur les autres nouveautés du langage C ++ ou communiquer personnellement avec vos collègues sur les avantages, consultez la conférence C ++ Russia. La prochaine se tiendra le 6 octobre à Nijni Novgorod .

Si vous avez des problèmes liés au C ++ et que vous souhaitez améliorer quelque chose dans le langage ou si vous souhaitez simplement discuter des innovations possibles, alors bienvenue sur https://stdcpp.ru/ .

Eh bien, si cela vous surprend que Yandex.Taxi a un grand nombre de tâches qui ne sont pas liées aux graphiques, alors j'espère que cela s'est avéré être une agréable surprise pour vous :) Venez nous rendre visite le 11 octobre , nous parlerons de C ++ et plus encore.