À un niveau abstrait, Coroutines a séparé l'idée d'avoir un état d'exécution de l'idée d'avoir un fil d'exécution.
SIMD (single instruction multiple data) a plusieurs "threads d'exécution" mais un seul état d'exécution (il ne fonctionne que sur plusieurs données). On peut dire que les algorithmes parallèles sont un peu comme ça, en ce sens que vous avez un «programme» exécuté sur des données différentes.
Le thread a plusieurs "threads d'exécution" et plusieurs états d'exécution. Vous avez plus d'un programme et plus d'un thread d'exécution.
Coroutines a plusieurs états d'exécution, mais ne possède pas de thread d'exécution. Vous avez un programme et le programme a un état, mais il n'a pas de thread d'exécution.
L'exemple le plus simple de coroutines sont les générateurs ou énumérables d'autres langages.
En pseudo code:
function Generator() {
for (i = 0 to 100)
produce i
}
Le Generatorest appelé, et la première fois qu'il est appelé, il revient 0. Son état est mémorisé (son état varie avec l'implémentation des coroutines), et la prochaine fois que vous l'appelez, il continue là où il s'était arrêté. Donc, il renvoie 1 la prochaine fois. Puis 2.
Enfin, il atteint la fin de la boucle et tombe à la fin de la fonction; la coroutine est terminée. (Ce qui se passe ici varie en fonction du langage dont nous parlons; en python, cela lève une exception).
Les coroutines apportent cette capacité au C ++.
Il existe deux types de coroutines; empilable et sans pile.
Une coroutine sans pile ne stocke que les variables locales dans son état et son emplacement d'exécution.
Une coroutine empilée stocke une pile entière (comme un thread).
Les coroutines sans pile peuvent être extrêmement légères. La dernière proposition que j'ai lue consistait essentiellement à réécrire votre fonction en quelque chose d'un peu comme un lambda; toutes les variables locales entrent dans l'état d'un objet, et les étiquettes sont utilisées pour sauter de / vers l'emplacement où la coroutine "produit" des résultats intermédiaires.
Le processus de production d'une valeur est appelé «rendement», car les coroutines sont un peu comme le multithreading coopératif; vous cédez le point d'exécution à l'appelant.
Boost a une implémentation de coroutines empilées; il vous permet d'appeler une fonction à céder pour vous. Les coroutines empilées sont plus puissantes, mais aussi plus chères.
Il y a plus dans les coroutines qu'un simple générateur. Vous pouvez attendre une coroutine dans une coroutine, ce qui vous permet de composer des coroutines de manière utile.
Les coroutines, comme if, les boucles et les appels de fonctions, sont un autre type de "goto structuré" qui vous permet d'exprimer certains modèles utiles (comme les machines à états) d'une manière plus naturelle.
L'implémentation spécifique de Coroutines en C ++ est un peu intéressante.
À son niveau le plus élémentaire, il ajoute quelques mots-clés à C ++:, co_return co_await co_yieldainsi que certains types de bibliothèques qui fonctionnent avec eux.
Une fonction devient une coroutine en ayant l'une de celles-ci dans son corps. Donc, d'après leur déclaration, ils sont indiscernables des fonctions.
Lorsqu'un de ces trois mots-clés est utilisé dans un corps de fonction, un examen obligatoire standard du type de retour et des arguments se produit et la fonction est transformée en coroutine. Cet examen indique au compilateur où stocker l'état de la fonction lorsque la fonction est suspendue.
La coroutine la plus simple est un générateur:
generator<int> get_integers( int start=0, int step=1 ) {
for (int current=start; true; current+= step)
co_yield current;
}
co_yieldsuspend l'exécution des fonctions, stocke cet état dans le generator<int>, puis renvoie la valeur de à currenttravers le generator<int>.
Vous pouvez boucler sur les entiers renvoyés.
co_awaitpendant ce temps, vous permet d'épisser une coroutine sur une autre. Si vous êtes dans une coroutine et que vous avez besoin des résultats d'une chose attendue (souvent une coroutine) avant de progresser, vous y êtes co_await. S'ils sont prêts, vous procédez immédiatement; sinon, vous suspendez jusqu'à ce que l'attendable que vous attendez soit prêt.
std::future<std::expected<std::string>> load_data( std::string resource )
{
auto handle = co_await open_resouce(resource);
while( auto line = co_await read_line(handle)) {
if (std::optional<std::string> r = parse_data_from_line( line ))
co_return *r;
}
co_return std::unexpected( resource_lacks_data(resource) );
}
load_dataest une coroutine qui génère une std::futurelorsque la ressource nommée est ouverte et que nous parvenons à analyser jusqu'au point où nous avons trouvé les données demandées.
open_resourceet read_lines sont probablement des coroutines asynchrones qui ouvrent un fichier et en lisent des lignes. Le co_awaitconnecte l'état de suspension et prêt de load_dataà leur progression.
Les coroutines C ++ sont beaucoup plus flexibles que cela, car elles ont été implémentées comme un ensemble minimal de fonctionnalités de langage en plus des types d'espace utilisateur. Les types d'espace utilisateur définissent efficacement ce que co_return co_awaitet co_yield signifient - j'ai vu des gens l'utiliser pour implémenter des expressions optionnelles monadiques de sorte qu'un co_awaitsur un optionnel vide propage automatiquement l'état vide vers le optionnel externe:
modified_optional<int> add( modified_optional<int> a, modified_optional<int> b ) {
return (co_await a) + (co_await b);
}
au lieu de
std::optional<int> add( std::optional<int> a, std::optional<int> b ) {
if (!a) return std::nullopt;
if (!b) return std::nullopt;
return *a + *b;
}
