Informatique distribuée vs threads

Question

Quelle est la similitude entre l'informatique distribuée et le threading? J'ai trouvé deux articles qui aboutissaient à des conclusions opposées:

"Le multi-threading est plus simple que la mise en réseau. En quoi le threading est-il simple et similaire au code réseau ""

http://software.intel.com/file/14723

(cela me donne l'impression qu'ils sont si similaires qu'après l'encapsulation, ces deux approches pourraient être réalisées avec le même code - mais je me trompe peut-être)

"Note sur l'informatique distribuée"

http://research.sun.com/techrep/1994/abstract -29.html

(et cela met une distinction forte)

Je suis sûr que la vérité est quelque part entre les deux. Quel est le juste milieu? Existe-t-il des technologies qui unissent ces deux paradigmes? Ou bien de telles tentatives ont-elles échoué en raison de différences fondamentales entre la mise en réseau et la concurrence?

Answer 1

Je ne les ai jamais trouvés très similaires. Permettez-moi de définir pour les besoins de cet article un " nœud " être un thread matériel en cours d'exécution sur une machine. Ainsi, une machine à quatre cœurs est composée de quatre nœuds, ainsi que d’un cluster de quatre processeurs simples.

Chaque nœud exécutera généralement certains traitements, et il faudra prévoir un type de communication inter-nœud. Habituellement, la première instance de cette communication indique au nœud quoi faire. Pour cette communication, je peux utiliser la mémoire partagée, les sémaphores, les fichiers partagés, les canaux nommés, les sockets, les appels de procédure à distance, le COM distribué, etc. Cependant, les plus faciles à utiliser, la mémoire partagée et les sémaphores, ne sont généralement pas disponibles sur un réseau. Les fichiers partagés peuvent être disponibles, mais les performances sont généralement médiocres. Les sockets ont tendance à être le choix le plus courant et le plus flexible sur un réseau, plutôt que les mécanismes plus sophistiqués. À ce stade, vous devez gérer les détails de l’architecture réseau, notamment la latence, la bande passante, la perte de paquets, la topologie du réseau, etc.

.

Si vous démarrez avec une file d'attente de travail, les nœuds d'un même ordinateur peuvent utiliser une simple mémoire partagée pour effectuer des tâches. Vous pouvez même écrire sans verrou et cela fonctionnera de manière transparente. Avec les nœuds sur un réseau, où mettez-vous la file d'attente? Si vous le centralisez, cette machine risque de subir des coûts très élevés en bande passante. Essayez de le distribuer et les choses deviennent très compliquées très rapidement.

Ce que j’ai trouvé, en général, c’est que les personnes qui s’attaquent à ce type d’architecture parallèle ont tendance à choisir des problèmes parallèles embarrassants à résoudre. Le lancer de rayons vient à l'esprit. Il n'y a pas beaucoup de communication inter-nœuds requise, mis à part la distribution des tâches. Certes, il y a beaucoup de problèmes comme celui-ci, mais je trouve un peu trompeur de suggérer que l'informatique distribuée est essentiellement la même chose que le threading.

Maintenant, si vous allez écrire un thread qui se comporte de manière identique à un système distribué, en utilisant le transfert de message pur et en ne supposant aucun thread comme étant le "principal". un et tel, alors oui, ils vont être très similaires. Mais ce que vous avez fait est de prétendre avoir une architecture distribuée et de l’implémenter dans des threads. Le fait est que le threading est un cas de parallélisme beaucoup plus simple que le vrai calcul distribué. Vous pouvez résumer les deux problèmes en un seul problème, mais en choisissant la version la plus difficile et en s’y tenant strictement. Et les résultats ne seront pas aussi bons qu'ils pourraient l'être lorsque tous les nœuds sont locaux à une machine. Vous ne tirez pas parti du cas particulier.

Answer 2

La distribution de l'informatique s'effectue sur plusieurs machines indépendantes différentes, généralement avec des systèmes d'exploitation parfois spécialisés. C'est plus difficile parce que l'interconnexion des machines est beaucoup moins importante et qu'il est donc très difficile de résoudre les problèmes nécessitant beaucoup d'accès rapide et aléatoire à l'ensemble du jeu de données.

De manière générale, vous avez besoin de bibliothèques spécialisées pour résoudre les problèmes informatiques distribués et déterminer comment attribuer des nœuds aux problèmes et gérer les données.

Je me demande vraiment s’ils parviennent à des conclusions différentes parce qu’ils essaient de résoudre les mauvais problèmes sur chaque plate-forme. Certains problèmes s’appliquent très bien à des machines très interconnectées et peuvent tirer parti des superordinateurs d’alimentation. D'autres problèmes peuvent être traités sur des modèles simplement distribués. En général, les superordinateurs peuvent résoudre un plus grand nombre de problèmes, mais sont beaucoup plus spécialisés et coûteux.

Answer 3

La différence semble revenir à l'état de partage des threads, les processus transmettent des messages.

Vous devez décider de la manière dont vous souhaitez conserver l'état de votre application avant d'en choisir un.

Il est facile de commencer à partager l’état de partage. Toutes les données et variables y sont présentes. Mais une fois que les blocages / conditions de course sont entrés, il est difficile de les modifier / échelonner.

Le passage de message (par exemple, Erlang) nécessite une approche différente de la conception. Vous devez dès le début réfléchir aux possibilités de simultanéité, mais l'état de chaque processus distribué est isolé, ce qui facilite le traitement des problèmes de verrouillage / contournement.

Answer 4

Je pense qu'il est beaucoup plus utile de comparer des processus avec des approches d'informatique répartie que de comparer des threads avec elle. Les threads existent dans un même processus et partagent les mêmes données et la même mémoire. Ce n'est pas possible sur plusieurs machines. Les processus, par contre, ont leur propre mémoire, même si dans certains cas, elle contient exactement les mêmes données qu'un autre processus (après un fork (), par exemple). Cela pourrait être réalisé sur un réseau.

Ce qui ajoute un poids supplémentaire à cette analogie est le fait que de nombreux outils utilisés pour la communication entre processus sont transparents pour le réseau. Un bon exemple serait les sockets unix, qui utilisent la même interface que les sockets réseau (à l’exception du code de connexion).

Answer 5

Oui, au moment de l’élaboration, l’approche est très similaire, mais leur utilisation est très différente. Je ne comprends pas très bien votre idée, mais dites-moi si je me trompe: lorsque nous parlons d’informatique distribuée, nous supposons plus d’un code de traitement de serveur ou d’ordinateur dans la même application, mais lorsque nous parlons de multi-threading, parlent de traiter différents threads de l'application en même temps sur le même ordinateur. Vous pouvez penser comme exemple d’informatique distribuée, dans une application accédant à un service Web situé sur Internet. Deux ordinateurs différents travaillent dans la même application.

Si vous voulez un exemple de multi-threading, imaginez une application essayant de trouver un grand nombre premier. Si vous n'utilisez pas le multi-threading, vous ne pourrez plus voir ou faire quoi que ce soit dans l'application au moment où il calcule le prochain nombre premier (peut être une durée de vie ou plus) car l'application est ne répond pas pendant que travaille dans le calcul.

Vous pouvez aussi les mélanger: comme exemple plus complexe, vous pouvez toujours utiliser le multi-threading pour accéder à différents services Web en même temps par la même application, ceci afin de rendre votre application réactive même si la connexion n'est pas établie. quand l'un des serveurs.

Answer 6

Je pense que ces deux documents ne peuvent pas être facilement comparés. Le document d'Intel est une sorte d'introduction au threading, et ils essaient de l'expliquer en trouvant des analogies avec l'informatique en réseau, ce qui est un peu étrange et trompeur pour moi. Je ne sais pas pourquoi ils ont choisi une telle façon de présenter le filetage, peut-être vis-à-vis de personnes familiarisées avec le réseautage, probablement plus connu ou au moins reconnu que le filetage.

Le document de Sun, en revanche, est un article sérieux décrivant toutes les difficultés liées à la programmation distribuée. Tout ce que je peux faire, c'est simplement confirmer ce qu'ils y disent.

À mon avis, une abstraction qui tente de masquer le fait qu'un objet soit distant est néfaste car elle entraîne généralement une très mauvaise performance. Le programmeur doit être conscient de l'éloignement d'un objet pour pouvoir l'invoquer efficacement.