Processus vs threads

Question

Comment décider d'utiliser des threads ou de créer un processus séparé dans votre application pour obtenir le parallélisme.

Answer 1

Les fils sont plus légers et permettent de fabriquer plusieurs "ouvriers". juste pour utiliser tous les processeurs ou cœurs disponibles, il vaut mieux utiliser des threads.

Lorsque vous avez besoin que les travailleurs soient mieux isolés et plus robustes, comme avec la plupart des serveurs, optez pour des sockets. Lorsqu'un thread se bloque gravement, il arrête généralement tout le processus, y compris les autres threads travaillant dans ce processus. Si un processus tourne au vinaigre et meurt, il ne touche à aucun autre processus. Ils peuvent donc poursuivre leur activité comme si de rien n'était.

Answer 2

Les processus ont une mémoire plus isolée. Ceci est important pour un certain nombre de raisons:

• Il est plus difficile pour une seule tâche de bloquer les autres tâches.
• Plus de mémoire sera disponible par processus. Ceci est important pour les grandes applications hautes performances telles qu'Apache ou les serveurs de bases de données, tels que Postgres. Ceci est important pour la mémoire allouée et les fichiers mappés en mémoire.

Answer 3

Le degré de parallélisme dépend principalement des processeurs / cœurs physiques disponibles sur votre machine. Si vous possédez une machine à processeur unique / principal, des processus distincts peuvent entraîner une surcharge. Les fils seraient généralement préférés dans ce cas.

Si vous avez plusieurs cœurs / processeurs, en fonction de chaque processus / thread, vous pouvez opter pour des processus si la surcharge est justifiée. Les processus ont évidemment un niveau d'isolation de mémoire bien supérieur aux threads - mais dans le même temps, sous Windows, les processus sont assez lourds par rapport aux threads.

Bien sûr, les threads peuvent partager des données dans le même processus - mais là encore, vous devrez synchroniser l'accès aux données partagées - pour éviter un état corrompu. Le partage de données entre processus est plus impliqué, la surcharge (ce qui est plus efficace qu'une simple synchronisation de thread) dépend des mécanismes utilisés tels que les canaux nommés, la communication basée sur des sockets personnalisés, l'utilisation d'un framework de communication à distance, d'un fichier / d'une base de données partagé, etc.

Answer 4

En règle générale, vous devez utiliser des processus lorsque les flux d'exécution individuels n'ont pas besoin de partager des données globales et que vous souhaitez que chacun d'eux soit protégé de l'autre.

Answer 5

Quelques liens qui pourraient vous aider à décider, j'espère:

http: / /blog.labnotes.org/2006/08/29/why-processes-scale-better-than-threads/ http://www.jroller.com/cpurdy/entry/fastcgi_not_so_fast

Answer 6

Sous Windows, les processus sont plus lourds à créer que les threads. Ainsi, si vous avez plusieurs tâches plus petites, un thread ou un pool de threads serait préférable. Ou utilisez un pool de processus pour recycler les processus. De plus, le partage d'état entre processus est plus fastidieux que le partage d'état entre threads. Mais encore une fois: les threads pourraient déstabiliser un processus complet en prenant d’autres threads avec lui. Si vous voulez minimiser les chances que cela se produise, vous pouvez opter pour des processus distincts. AppDomains de .Net pourrait être un terrain d'entente entre les deux.