Le destructeur de std::thread effectue une vérification implicite de son état interne. Si le thread reste joignable—c'est-à-dire qu'il représente un thread d'exécution actif qui n'a pas encore été joint ou détaché—le destructeur invoque std::terminate pour empêcher le programme de continuer avec un thread potentiellement rogue. Cette conception impose une gestion explicite du cycle de vie mais crée une responsabilité significative en matière de sécurité des exceptions et de chemins de retour anticipés.
std::jthread, introduit dans C++20, élimine ce risque en encapsulant l'annulation coopérative et la synchronisation dans son design RAII. Son destructeur signale d'abord l'annulation via un std::stop_source interne, puis invoque automatiquement join(), bloquant jusqu'à ce que le thread termine son exécution. Cela garantit que le thread se termine gracieusement avant que l'objet ne soit détruit, éliminant la possibilité d'une terminaison accidentelle sans intervention manuelle.
// Dangereux : std::thread void risky_task() { std::thread t([]{ /* travail en arrière-plan */ }); if (config_error) return; // std::terminate() appelé ici ! t.join(); } // Sûr : std::jthread void safe_task() { std::jthread t([](std::stop_token st) { while (!st.stop_requested()) { /* travail */ } }); if (config_error) return; // Sûr : le destructeur demande l'arrêt et rejoint }
Considérez une application de trading à haute fréquence qui crée un thread de récupération de données de marché pour traiter les devis en entrée. Lors de l'initialisation, si la configuration réseau s'avère invalide, la fonction retourne prématurément, détruisant l'objet std::thread avant d'appeler join(). Ce scénario se produit fréquemment dans des applications asynchrones liées aux entrées/sorties où l'acquisition de ressources peut échouer après la création du thread, entraînant des crashes immédiats dans des environnements de production.
Une approche envisagée consistait à envelopper le thread dans un bloc try-catch manuel, garantissant que join() s'exécute avant chaque chemin de retour et gestionnaire d'exception. Bien que explicite, cela s'est avéré fragile ; ajouter de nouveaux points de sortie ou refactoriser a fréquemment introduit des régressions où la logique de jointure était omise, entraînant des appels sporadiques à std::terminate pendant la récupération d'erreurs.
Une autre solution évaluée impliquait une classe ScopeGuard personnalisée qui stockait la référence du thread et le rejoignait dans son destructeur. Bien que cela encapsule la logique de sécurité, cela répliquait une fonctionnalité déjà standardisée dans la bibliothèque et nécessitait de maintenir du code répétitif dans plusieurs modules, augmentant la dette technique et la charge de révision.
L'équipe a finalement adopté std::jthread après la migration vers C++20. En remplaçant std::thread, le destructeur a automatiquement signalé l'annulation via std::stop_token et a attendu la complétion du thread sans blocs de synchronisation manuels. Cela a levé le fardeau d'assurer le nettoyage lors du déroulement de la pile en cas d'exceptions ou de retours anticipés, résultant en une base de code à la fois plus sûre et plus maintenable.
Pourquoi invoquer join() deux fois sur un std::thread entraîne-t-il un comportement indéfini, et comment std::jthread empêche-t-il cela de manière programmatique ?
Un objet std::thread suit si elle détient une poignée valide vers un thread d'exécution. Une fois que join() est appelé, le thread devient non-joignable, mais la norme ne mandate pas que des appels subséquents vérifient en toute sécurité cet état. Invoquer join() à nouveau viole la précondition que le thread doit être joignable, entraînant un comportement indéfini se manifestant généralement par des crashes, des blocages ou des fuites de ressources.
std::jthread prévient cela en rendant join() idempotent grâce à un suivi de l'état interne robuste. Son destructeur appelle join() uniquement si le thread est joignable, et les appels explicites ultérieurs ne font rien en toute sécurité, imitant le comportement des opérations de réinitialisation des pointeurs intelligents et évitant les erreurs de double-jointure accidentelles.
Comment le std::stop_token de std::jthread permet-il l'annulation coopérative, et pourquoi est-ce supérieur aux primitives d'interruption de thread asynchrones ?
std::jthread associe chaque thread avec un std::stop_source et passe un std::stop_token à la fonction d'entrée du thread. Le travailleur vérifie périodiquement stop_requested() pour quitter sa boucle proprement, garantissant que les invariants sont maintenus et que les mutex sont déverrouillés. Cela contraste fortement avec std::thread, où l'interruption nécessite des appels spécifiques à la plateforme comme pthread_cancel ou TerminateThread, qui arrêtent de manière forcée l'exécution en plein milieu d'une instruction et peuvent laisser des ressources partagées dans un état corrompu ou verrouillé.
Que se passe-t-il avec le signal d'annulation lorsque un std::jthread est déplacé vers un autre objet, et le thread en cours observe-t-il le transfert ?
Lorsque std::jthread est déplacé, l'objet source renonce à la propriété de la poignée de thread sous-jacente et du std::stop_source, devenant vide et non-joignable. L'objet de destination assume le contrôle du thread. Crucialement, le std::stop_token passé à la fonction de travail reste valide car il fait référence à l'état d'arrêt géré par le std::stop_source, qui persiste tant que n'importe quel token ou source y fait référence. Le thread continue de s'exécuter sous la nouvelle propriété de l'objet jthread, et les demandes d'annulation via la nouvelle poignée parviennent toujours au travailleur d'origine sans problème.