From Wikipedia
Dans certains les systèmes informatiques concurrents, la communication entre les composants concurrents est cachée au programmeur (par exemple, en utilisant des futurs), alors que dans d'autres, elle doit être gérée explicitement. communication explicite peut être divisée en deux classes:
communication de mémoire partagée composants simultanés communiquent en modifiant le contenu des emplacements de mémoire partagée (illustrée par Java et C#). Ce style de programmation simultanée nécessite généralement l'application d'une certaine forme de verrouillage (par exemple, mutex, sémaphores ou moniteurs) pour coordonner les threads.
passage de messages communication composantes simultanées communiquent par l'échange de messages (illustrés par Erlang et occam). L'échange de messages peut être effectué de manière asynchrone, ou peut utiliser un style de rendez-vous dans lequel l'expéditeur bloque jusqu'à ce que le message soit reçu. Le passage de message asynchrone peut être fiable ou non fiable (parfois appelé "envoyer et prier"). La concurrence entre les messages a tendance à être beaucoup plus facile à raisonner que la concurrence partagée, et est généralement considérée comme une forme plus robuste de programmation simultanée. Une grande variété de théories mathématiques pour comprendre et analyser les systèmes de transmission de messages sont disponibles, y compris le modèle Acteur et divers calculs de processus. Le passage de message peut être efficacement implémenté sur des multiprocesseurs symétriques, avec ou sans mémoire cohérente partagée.
La mémoire partagée et l'accès simultané aux messages ont des caractéristiques de performance différentes; en général (mais pas toujours), le surdébit de mémoire par processus et le surdébit de commutation de tâche sont plus faibles dans un système de transmission de messages, mais le surdébit du message lui-même est supérieur à celui d'un appel de procédure. Ces différences sont souvent dépassées par d'autres facteurs de performance. La pièce dit ci-dessus que les communications asynchrones peuvent être peu fiables, mais qui peut être évité en utilisant un système de mise en attente transactionnel (JMS sur MQSeries, OpenMQ, etc ...)
mon grain de sel.
Les deux paradigmes ne sont pas en concurrence, ils sont différents dans le but, Nous parlons de communications asynchrones vs synchrones. Pour l'évolutivité, il est généralement préférable de faire de l'asynchrone chaque fois que cela est possible, car vous pouvez toujours reporter à un autre processus ou traiter les résultats chaque fois que vous avez une bande passante supplémentaire. Il n'est pas toujours possible de diviser les algorithmes en morceaux de travail asynchrones.
Je ne vois pas de guerres saintes ici. Le passage des messages est plus propre et certainement plus sûr, mais parfois c'est trop lent. Certains modèles de calcul bénéficient d'un état partagé, d'autres du passage de message. Tout dépend de quel est votre problème. – liori