C++11: Ce qui arrive à un décollement de la thread principale en cas de() ferme?

Question

Supposons je commence un std::thread puis detach() , de sorte que le fil continue à exécuter même si l' std::thread qu'une fois représenté, est hors de portée.

De plus, supposons que le programme ne dispose pas d'un protocole fiable pour rejoindre le détachement du filetage[1], de sorte que le détachement du thread s'exécute toujours lorsque main() des sorties.

Je ne trouve rien dans la norme (plus précisément dans la N3797 C++14 projets), qui décrit ce qui doit arriver, ni 1.10 ni de 30,3 contenir pertinentes libellé.

[1] un autre, probablement équivalent, la question est: "un thread détaché jamais être rejoint à nouveau", parce que le protocole que vous êtes à inventer pour rejoindre, la signalisation de la partie devra être effectué alors que le fil était encore en cours d'exécution, et l'OS planificateur peut décider de mettre le fil de dormir pendant une heure juste après la signalisation a été réalisée avec aucun moyen pour la fin de réception de détecter de manière fiable que le thread en fait terminé.

Answer 1

Détacher Les Threads

Selon http://en.cppreference.com/w/cpp/thread/thread/detach :

Sépare le thread d'exécution de l'objet thread, permettant l'exécution continue de façon indépendante. Toutes les ressources allouées seront libérés une fois que le thread s'arrête.

À partir de http://pubs.opengroup.org/onlinepubs/009695299/functions/pthread_detach.html :

Le pthread_detach() la fonction doit indiquer à la mise en œuvre que le stockage pour le thread thread peut être récupérée lors de ce thread se termine. Si le thread n'a pas résilié, pthread_detach() ne doit pas il cause de la fin. L'effet de plusieurs pthread_detach() appelle sur le même thread cible est spécifiée.

Détachement de threads est principalement pour l'économie des ressources, dans le cas où l'application n'a pas besoin d'attendre qu'un thread à la fin (par exemple, les démons, qui doit courir jusqu'à la fin du processus):

1. Pour libérer de l'application poignée de côté: On peut laisser un std::thread objet hors de portée sans avoir à se déplacer, ce qui conduit normalement à un appel à l' std::terminate() sur la destruction.
2. Pour permettre à l'OS de nettoyage du fil de ressources spécifiques (TCB) automatiquement dès que le thread s'arrête, parce que nous avons spécifié explicitement, que nous ne sommes pas intéressés à joindre le fil plus tard, donc, on ne peut pas rejoindre une déjà détaché fil.

Tuer Des Threads

Le comportement sur l'arrêt du processus est la même que pour le thread principal, qui pourrait au moins attraper quelques signaux. Si oui ou non les autres threads peuvent traiter les signaux n'est pas si important que cela, comme on pouvait rejoindre ou de résilier les autres threads dans le thread principal du gestionnaire de signal d'invocation. Question connexe: la Propagation du Signal (SIGINT) à C++11 fils

Comme déjà dit, n'importe quel thread, que ce soit détaché ou non, va mourir avec ses processus sur la plupart des Systèmes d'exploitation (http://en.wikipedia.org/wiki/Thread_(computing)). Le processus lui-même peut être résilié par l'élévation d'un signal, en appelant exit() ou par retour de la fonction principale. Cependant, C++11 ne peut pas et ne tente pas de définir exactement le comportement de l'OS sous-jacent, tandis que les développeurs d'une machine virtuelle Java peut sûrement résumé de telles différences, dans une certaine mesure. Autant que je sache, exotique processus et les modèles de thread sont habituellement trouvés sur les anciennes plates-formes (dont C++11 ne sera probablement pas porté) et de divers systèmes embarqués, ce qui pourrait avoir un spécial et/ou de la langue mise en œuvre de bibliothèque et également limitée de la langue.

Le Support Des Threads

Si les threads ne sont pas pris en charge std::thread::get_id() doit retourner un id non valide (par défaut construits std::thread::id) qu'il y a une plaine de processus, qui n'a pas besoin d'un objet thread à exécuter et le constructeur de l' std::thread jette std::system_error. C'est comme ça que je comprends C++11 en conjonction avec les Systèmes d'exploitation d'aujourd'hui. Si il y a un OS avec filetage, de soutien, ce qui ne veut pas lancer un thread principal dans ses processus, laissez-moi savoir.

Le Contrôle De Threads

Si l'on doit garder le contrôle sur un thread pour l'arrêt correct, on peut faire cela en utilisant des primitives de synchronisation et/ou une sorte de drapeaux. Toutefois, Dans ce cas, la fixation d'un arrêt de l'indicateur suivi par une jointure est la façon que je préfère, car il n'y a pas de point de complexité croissante en détachant les threads, les ressources seraient libérés en même temps de toute façon, les quelques octets de l' std::thread objet vs. plus grande complexité et peut-être plus primitives de synchronisation doit être acceptable.

Answer 2

Le sort du fil après le programme des sorties est un comportement indéterminé. mais un système d'exploitation moderne va nettoyer tous les threads créés par le processus de fermeture.

Lors du détachement d'un std::thread, ces trois conditions, continuera à tenir

1. *this n'est plus propriétaire de n'importe quel thread
2. recrutables() est toujours égale à false
3. get_id() sera égal à std::thread::id()