Est-il judicieux de remplacer boost :: thread et boost :: mutex par des équivalents c ++ 11?

Il existe plusieurs différences entre Boost.Thread et la bibliothèque de threads standard C ++ 11:

• Boost prend en charge l’annulation de threads, les threads C ++ 11 ne le font pas
• C ++ 11 prend en charge std::async , mais Boost ne le fait pas
• Boost a un boost::shared_mutex pour le boost::shared_mutex multi-lecteur / single-writer. std::shared_timed_mutex est disponible uniquement depuis C ++ 14 ( N3891 ), alors que std::shared_mutex n’est disponible que depuis C ++ 17 ( N4508 ).
• Les délais d’attente C ++ 11 sont différents des délais d’attente Boost (bien que cela devrait bientôt changer maintenant Boost.Chrono a été accepté).
• Certains noms sont différents (par exemple, boost::unique_future vs std::future )
• La sémantique de std::thread est différente de boost::thread — Boost utilise boost::bind , ce qui nécessite des arguments copiables. std::thread permet aux types de déplacement tels que std::unique_ptr d’être transmis en tant qu’arguments. En raison de l’utilisation de boost::bind , la sémantique des espaces réservés tels que _1 dans les expressions de liaison nestedes peut également être différente.
• Si vous n’appelez pas explicitement join() ou detach() alors l’opérateur destructeur et assignation boost::thread appellera detach() sur l’object thread détruit / assigné. Avec un object C ++ 11 std::thread , cela entraînera un appel à std::terminate() et abandonnera l’application.

Pour clarifier le point concernant les parameters de déplacement uniquement, voici C ++ 11 valide, et transfère la propriété de l’ int de std::unique_ptr temporaire au paramètre de f1 lorsque le nouveau thread est démarré. Cependant, si vous utilisez boost::thread cela ne fonctionnera pas, car il utilise boost::bind interne et std::unique_ptr ne peut pas être copié. Il existe également un bogue dans la bibliothèque de threads C ++ 11 fournie avec GCC qui empêche ce fonctionnement, car elle utilise également std::bind dans l’implémentation.

 void f1(std::unique_ptr); std::thread t1(f1,std::unique_ptr(new int(42))); 

Si vous utilisez Boost, vous pouvez probablement passer aux threads C ++ 11 sans peine si votre compilateur le supporte (par exemple, les versions récentes de GCC sous Linux ont une implémentation complète de la bibliothèque de threads C ++ 11 disponible dans -std=c++0x Mode -std=c++0x ).

Si votre compilateur ne prend pas en charge les threads C ++ 11, vous pourrez peut-être obtenir une implémentation tierce telle que Just :: Thread , mais cela rest une dépendance.

std::thread est largement modélisé après boost::thread , avec quelques différences :

• Non-copyable, one-handle-maps-to-one-os-thread de boost, la sémantique est conservée. Mais ce fil est mobile pour permettre le retour du fil des fonctions de l’usine et le placement dans des conteneurs.
• Cette proposition ajoute une annulation au boost::thread , ce qui est une complication importante. Ce changement a également un impact important non seulement sur le thread, mais également sur le rest de la bibliothèque de threads C ++. On croit que ce grand changement est justifiable en raison de l’avantage.
  • Le destructeur de thread doit maintenant appeler cancel avant de se détacher pour éviter toute fuite accidentelle de threads enfants lorsque les threads parents sont annulés.
  • Un membre de détachement explicite est maintenant requirejs pour activer le détachement sans annuler.
• Les concepts de handle de thread et d’identité de thread ont été séparés en deux classes (ils sont la même classe dans boost::thread ). Cela permet de faciliter la manipulation et le stockage de l’identité du thread.
• La possibilité de créer un identifiant de thread qui soit garanti égal à aucun autre thread jointable a été ajoutée ( boost::thread ne l’a pas). C’est pratique pour le code qui veut savoir s’il est exécuté par le même thread qu’un appel précédent (les mutex récursifs sont un exemple concret).
• Il existe une “porte dérobée” pour obtenir le handle de thread natif afin que les clients puissent manipuler les threads à l’aide du système d’exploitation sous-jacent, si désiré.

Ceci est à partir de 2007, donc certains points ne sont plus valides: boost::thread a maintenant une fonction native_handle , et, comme le font remarquer les commentateurs, std::thread ne contient plus d’annulation.

Je n’ai pu trouver aucune différence significative entre boost::mutex et std::mutex .

Il y a une raison pour ne pas migrer vers std::thread .

Si vous utilisez des liens statiques, std::thread devient inutilisable à cause de ces bogues / fonctionnalités gcc:

• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52590
• http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57740

À savoir, si vous appelez std::thread::detach ou std::thread::join cela conduira soit à une exception, soit à un crash, alors que boost::thread fonctionnera correctement dans ces cas.

Cas d’entreprise

Si vous écrivez des logiciels pour l’entreprise qui doit fonctionner sur une variété de systèmes d’exploitation modérée à large et, par conséquent, construits avec une variété de compilateurs et de versions de compilateurs (en particulier les plus anciens) sur ces systèmes d’exploitation, C ++ 11 au total pour le moment. Cela signifie que vous ne pouvez pas utiliser std::thread , et je vous recommande d’utiliser boost::thread .

Basic / Tech Startup Case

Si vous écrivez pour un ou deux systèmes d’exploitation, vous devez être sûr que vous n’avez besoin que de comstackr avec un compilateur moderne qui supporte principalement C ++ 11 (par exemple VS2015, GCC 5.3, Xcode 7) et vous n’êtes pas déjà dépendant de la bibliothèque boost, alors std::thread pourrait être une bonne option.

Mon expérience

Je m’intéresse personnellement aux bibliothèques renforcées, fortement utilisées, hautement compatibles et hautement cohérentes, telles que Boost versus une alternative très moderne. Cela est particulièrement vrai pour les sujets de programmation compliqués tels que le threading. En outre, j’ai connu un grand succès avec boost::thread (et en général en général) sur de nombreux environnements, compilateurs, modèles de boost::thread , etc.

Avec Visual Studio 2013, le std::mutex semble se comporter différemment du boost::mutex , ce qui m’a causé quelques problèmes (voir cette question ).

J’ai essayé d’utiliser shared_ptr à partir de std au lieu de boost et j’ai effectivement trouvé un bogue dans l’implémentation de gcc de cette classe. Mon application était en panne à cause du destructeur appelé deux fois (cette classe devrait être thread-safe et ne devrait pas générer de tels problèmes). Après avoir déménagé pour booster :: shared_ptr, tous les problèmes ont disparu. Les implémentations actuelles de C ++ 11 ne sont toujours pas matures.

Boost a également plus de fonctionnalités. Par exemple, l’en-tête dans la version std ne fournit pas de sérialiseur à un stream (c.-à-d. Cout << duration). Boost possède de nombreuses bibliothèques qui utilisent ses propres équivalents, etc., mais ne coopèrent pas avec les versions std.

En résumé, si vous avez déjà une application écrite en utilisant boost, il est plus prudent de garder votre code tel qu’il est au lieu de faire des efforts pour passer au standard C ++ 11.