Quelques discussions et quelques liens sur les mots de la programmation parallèle et concurrente.
La confluence d'un système concurrent est une propriété qui s'avère lorsque le résultat du calcul fait par ce système est indépendant de la stratégie d'ordonnancement de ses éléments constitutifs. Un système parallèle est typiquement confluent; pour un système concurrent, c'est beaucoup moins évident.
Informellement, un calcul est linéarisable s'il est fait d'une séquence d'opérations telles que pour chacune de ces opérations, les postconditions semblent prendre effet d'un seul coup; exprimé autrement, dans une séquence d'opérations , aucune des opérations ne laisse transparaître à l'extérieur d'elle-même de postconditions partiellement réalisées.
La linéarisabilité est une propriété importante des systèmes concurrents, au sens où elle permet de réaliser la cohérence séquentielle : a posteriori, il est possible de regarder l'histoire de l'exécution du système et d'en tirer une image cohérente pour tous les threads qui y ont participé.
Vous trouverez plus d'informations à ce sujet dans linearisabilite.html
Bien qu'on utilise souvent les termes « parallèle » et « concurrent » de manière interchangeable, ces deux termes ne sont pas exactement porteurs du même sens.
Je vous propose les définitions de quelques experts (parmi plusieurs).
Selon Robert Harper, professeur à Carnegie Mellon, le parallélisme et la concurrence n'ont a priori rien à voir l'un avec l'autre. De son point de vue, la concurrence est nécessaire autant dans les programmes séquentiels que dans les programmes parallèles. En effet, dans http://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/, texte de 2011, il écrit ce qui suit (les mises en relief sont de moi) :
« Concurrency is concerned with nondeterministic composition of programs (or their components). Parallelism is concerned with asymptotic efficiency of programs with deterministic behavior. Concurrency is all about managing the unmanageable: events arrive for reasons beyond our control, and we must respond to them. A user clicks a mouse, the window manager must respond, even though the display is demanding attention. Such situations are inherently nondeterministic, but we also employ pro forma nondeterminism in a deterministic setting by pretending that components signal events in an arbitrary order, and that we must respond to them as they arise. Nondeterministic composition is a powerful program structuring idea. Parallelism, on the other hand, is all about dependencies among the subcomputations of a deterministic computation. The result is not in doubt, but there are many means of achieving it, some more efficient than others. We wish to exploit those opportunities to our advantage. »
On voit que dans la vision qu'en donne Robert Harper, la concurrence intervient dans les cas d'indéterminisme a priori tels que les calculs asynchrones et dans les systèmes événementiels, alors que le parallélisme tient aux dépendances entre calculs déterministes (on suppose qu'il entend calculs s'exécutant potentiellement en même temps).
Dans une présentation de 2012 (http://concur.rspace.googlecode.com/hg/talk/concur.html#landing-slide), Rob Pike prétend que la concurrence n'est pas le parallélisme, mais plus encore : que la concurrence est préférable au parallélisme. Il définit la concurrence comme « Programming as the composition of independently executing processes », et le parallélisme comme « Programming as the simultaneous execution of (possibly related) computations ». Il ajoute que (traduction libre) :
Bien entendu, il montre par la suite comment son plus récent langage, Go, aide à en tirer profit. Pour un exemple simple d'exécution concurrente avec Go, voir ../Client-Serveur/TiPointsGo.html
Dans http://ghcmutterings.wordpress.com/2009/10/06/parallelism-concurrency/?ftw, texte de 2009, Simon Marlow, l'un des contributeurs au GHC, le compilateur Haskell le plus connu, distingue quant à lui ces deux concepts comme suit :
« A concurrent program is one with multiple threads of control. Each thread of control has effects on the world, and those threads are interleaved in some arbitrary way by the scheduler. We say that a concurrent programming language is non-deterministic, because the total effect of the program may depend on the particular interleaving at runtime. The programmer has the tricky task of controlling this non-determinism using synchronisation, to make sure that the program ends up doing what it was supposed to do regardless of the scheduling order. And that’s no mean feat, because there’s no reasonable way to test that you have covered all the cases. This is regardless of what synchronisation technology you’re using: yes, STM is better than locks, and message passing has its advantages, but all of these are just ways to communicate between threads in a non-deterministic language. »
Comme on peut le constater ici, Simon Marlow rejoint Robert Harper dans son association entre la concurrence et l'indéterminisme à l'exécution d'un programme. Ensuite :
« A parallel program, on the other hand, is one that merely runs on multiple processors, with the goal of hopefully running faster than it would on a single CPU. »
Il poursuit en blâmant la confusion entre ces deux idées sur les langages de programmation permettant des entités mutables :
« So where did this dangerous assumption that Parallelism == Concurrency come from? It’s a natural consequence of languages with side-effects: when your language has side-effects everywhere, then any time you try to do more than one thing at a time you essentially have non-determinism caused by the interleaving of the effects from each operation. So in side-effecty languages, the only way to get parallelism is concurrency; it’s therefore not surprising that we often see the two conflated.
However, in a side-effect-free language, you are free to run different parts of the program at the same time without observing any difference in the result. This is one reason that our salvation lies in programming languages with controlled side-effects. The way forward for those side-effecty languages is to start being more explicit about the effects, so that the effect-free parts can be identified and exploited. »
Comme vous pouvez le constater, il y a matière à débats quant au sens précis à donner à ces termes, même chez les experts.
Permettez-moi de citer (j'espère d'ailleurs avoir la formulation exacte) Hartmut Kaiser, dans sa présentation de 2014 nommée Plain Threads are the GOTO of todays computing (http://meetingcpp.com/index.php/tv14/items/26.html) : « Stop putting concurrency in your code. Use parallelism and you'll be fine »
Ce qu'est la concurrence : http://blogs.msdn.com/b/larryosterman/archive/2005/02/14/372508.aspx
J'aime celle-ci car elle est courte :
« Concurrency is two things that can happen independently.
Parallelism is two things happening at the same time. »
