Dans Windows C++, createThread() entraîne le ralentissement de certains threads si l'un d'entre eux effectue une opération très gourmande en ressources humaines. La volonté createProcess() pour atténuer ce problème ? Dans l'affirmative, est-ce que createProcess() Cela implique que le code doit résider dans un second exécutable, ou tout cela peut-il se faire à l'intérieur du même exécutable ?
Réponses
Trop de publicités?
La principale différence entre un processus et un thread est que chaque processus dispose de son propre espace mémoire, tandis que les threads partagent l'espace mémoire du processus dans lequel ils s'exécutent.
Si un thread est vraiment lié au processeur, il ne ralentira un autre thread que si tous deux s'exécutent sur le même cœur de processeur. createProcess ne résoudra pas ce problème, car un processus continuerait à être confronté au même problème.
Par ailleurs, sur quel type de machine utilisez-vous ce système ? A-t-elle plus d'un cœur ?
holtavolt
Points
2798
C'est peu probable - un processus est beaucoup plus "lourd" qu'un fil de discussion, et il est donc probable qu'il soit encore plus lent. Je ne suis pas sûr de ce que vous demandez à propos du deuxième exécutable, mais vous pouvez utiliser createProcess sur le même .exe.
http://msdn.microsoft.com/en-us/library/ms682425(v=vs.85).aspx
Il semble que vous cherchiez à résoudre des problèmes de performance, il serait donc peut-être utile d'essayer un profileur orienté vers les threads : http://software.intel.com/en-us/articles/using-intel-thread-profiler-for-win32-threads-philosophy-and-theory/
threeapples
Points
11
Chaque processus fournit les ressources nécessaires à l'exécution d'un programme. Un processus dispose d'un espace d'adressage virtuel, d'un code exécutable, de poignées ouvertes vers des objets du système, d'un contexte de sécurité, d'un identifiant de processus unique, de variables d'environnement, d'une classe de priorité, de tailles minimales et maximales pour l'ensemble de travail et d'au moins un fil d'exécution. Chaque processus démarre avec un seul thread, souvent appelé thread primaire, mais peut créer des threads supplémentaires à partir de n'importe lequel de ses threads.
Un thread est l'entité d'un processus dont l'exécution peut être programmée. Tous les threads d'un processus partagent son espace d'adressage virtuel et ses ressources système. En outre, chaque thread dispose de gestionnaires d'exceptions, d'une priorité d'ordonnancement, d'un stockage local, d'un identifiant unique et d'un ensemble de structures que le système utilisera pour sauvegarder le contexte du thread jusqu'à ce qu'il soit ordonnancé. Le contexte du thread comprend l'ensemble des registres de la machine du thread, la pile du noyau, un bloc d'environnement du thread et une pile utilisateur dans l'espace d'adressage du processus du thread. Les threads peuvent également avoir leur propre contexte de sécurité, qui peut être utilisé pour usurper l'identité d'un client.
rerun
Points
15285
La création d'un processus et la création d'un fil conducteur entraînent toutes deux une exécution supplémentaire dans un environnement où les ressources sont limitées. Cela signifie que, quelle que soit la manière dont vous effectuez le traitement parallèle, à un moment ou à un autre, vos autres lignes d'exécution impacteront le courant. C'est pour cette raison que l'on utilise des systèmes distribués pour les très gros problèmes qui se prêtent à la parallélisation. Les threads et les processus présentent des avantages et des inconvénients.
Fils
Les threads permettent une exécution séparée au sein d'un même espace d'adressage, ce qui signifie que vous pouvez partager des variables de données, des instances d'objets très facilement, mais cela signifie également que vous rencontrez beaucoup plus de problèmes de synchronisation. Ceux-ci sont pénibles et, comme vous pouvez le voir dans le nombre de fonction api n'est pas un sujet léger. Les threads sont un poids plus léger pour Windows que les processus et, en tant que tels, ils montent et descendent plus rapidement et utilisent moins de ressources pour leur maintenance. Les threads souffrent également du fait qu'un seul thread peut entraîner l'échec de l'ensemble du processus.
Processus
Les processus ont chacun leur propre espace d'adressage et se protègent ainsi contre l'effondrement par un autre processus, mais n'ont pas la capacité de communiquer facilement. Toute communication implique nécessairement un certain type d'IPC (Pipes, TCP, ...).
Il n'est pas nécessaire que le code se trouve dans un second exécutable ; il suffit que deux instances soient exécutées.
MSalters
Points
74024
Cela ne ferait qu'empirer les choses. Lors d'un changement de thread, l'unité centrale n'a besoin de changer que quelques registres. Étant donné que tous les threads d'un processus partagent la même mémoire, il n'est pas nécessaire de vider le cache. Mais lorsque l'on passe d'un processus à l'autre, on change également de mémoire mappée. Par conséquent, l'unité centrale doit vider le cache L1. C'est pénible.
(Le cache L2 est physiquement mappé, c'est-à-dire qu'il utilise des adresses matérielles. Celles-ci ne changent pas, bien entendu).
