.NET4.0, C#4.0, ParallelFX ... Qu'est ce que la programmation concurentielle?
A l'approche de grands évènements de communication chez Microsoft (dont la Professional
Developer Conference), on commence à avoir quelques suspicions sur ce
que sera le C#4.0 et .Net 4.0. Le framework ParallelFx qui est à la
base un projet Microsoft destiné à multi-threader facilement les applications et des requêtes (PLinq). Ce framework commence à atteindre un certain stade de maturité, il va d'ailleurs bientôt fêter son anniversaire. Peut être ferat-il partie intégrante de .NET 4 ? Bien des éléments nous portent à le croire.
A quoi sert ParallelFX ?
Tirer parti des architectures des processeurs modernes en divisant nos
applications en processus concurrents. Mais qu'est-ce que peut bien
signifier des processus concurrents ? Je concède que cette notion n'est
pas encore familière à tout le monde, si le sujet vous intéresse je
vous propose un bref descriptif puis quelques ressources francophones à ce sujet
en fin d'article. La division en processus concurrents n'est pas
toujours évidente à faire manuellement, intégrer nativement ParallelFX
au framework .NET et l'utilisation commune de cette technologie
pourrait dissiper certains détracteurs du framework l'attaquant sur la
performance.
Qu’est-ce que la programmation concurrentielle ?
La programmation concurrentielle consiste à diviser en plusieurs tâches
nos applications. Quand il n'y a pas d'interactions entre les tâches on
parle aussi de programmation parallèle qui est un cas particulier (et
le cas le plus simple) de programmation concurrentielle. Ces tâches
s'exécutent en parallèle donc il n'y a pas de temps mort et nos
applications peuvent tirer parti des processeurs multi-coeurs qui sont aujourd'hui en standard sur les PC (à part netbooks). Sur le papier c'est beau, mais si c'est encore peu utilisé c'est je pense pour ces trois raisons principales :
- Les développeurs ont rarement étés formés au multi-thread ou préfèrent aller au plus simple
- Si les threads touchent aux mêmes variables les résultats peuvent devenir aberrants. Mettons une application bancaire ou les évènements sont sur des threads différents. Si un client fait un retrait et un dépôt en même temps il se peut que seul une des deux opérations soit effective (lecture simultanée de la valeur initiale, seul le dernier processus à écrire sera pris en compte).
- Les interactions entre les threads sont assez imprévisibles et la loie de Murphy pousse ces applications à planter en production mais jamais lors du debug.
Quelles solutions apporte ParallelFX ?
Répartir sur des threads
indépendants, c'est assez facile même aujourd'hui sans ParallelFX.
ParallelFX facilite encore plus et peut par exemple transformer des « foreach » en « Parallel.ForEach » voire en « forall » (dans le cas de requêtes Plinq) qui lancera en parallèle toutes les itérations. De plus il propose le PLinq qui permet donc de multi-threader
automatiquement les requêtes. De ce fait ParallelFX porte déjà une
bonne solution au premier problème qui est la difficulté. Dans le cas
ou les trheads sont indépendant c'est parfait.
Mais quand les threads
doivent communiquer entre eux, il reste le risque de valeurs
incohérentes et d'erreur aléatoires. Comme en mathématiques quand deux threads parallèles se croisent, il y a risque d'erreur . A l'heure actuelle le moyen le plus simple c'est d'utiliser le mot clef lock quand nécessaire pour verrouiller l'accès aux variables aux autres threads et limiter le risque d'erreur.
Mais une autre solution plus simple semble avancer de chez Microsoft...
Un développeur Microsoft a récemment ouvert un blog (en) ICI sur les
mémoires transactionnelles logicielles (STM -> Software transactional memory).
Que sont ces « mémoires de transactions logicielles » ?
C'est un moyen en programmation concurrentielle de contrôler la mémoire partagée entre les processus. Les threads ont leurs copies des variables utilisées et la traite sans problème. Si une opération à exécuter sur de la mémoire partagée a eu lieu pendant l'exécution du thread, ce thread est ré-exécuté, sinon il remplace la valeur réelle. Certains feront l'analogie entre ces variables spéciales et les requêtes
Et mono dans tout ça?
Mono grâce à un étudiant français (Jérémie Laval) a déjà PLinq et ParallelFX de pas mal implémenté. Jérémie
a porté sa contribution subventionné par Google Summer Of Code
(opération où Google donnes quelques pièces aux étudiants qui
contribuent au logiciel libre). L'idée de cet article m'est venue de
ses hypothèses que désormais je partage sur l'implémentation future de
ParallelFX dans .NET4. Voici en français mon interprétation de la fin
de son (en) article : « En attente de nouvelles de la PDC2008 voir ce que Microsoft réserve à ParallelFX que je commence à implémenter ça dans Mono ». Plutôt bon signe non?
Liens:
Vous trouverez ici une présentation de ce qu’est ParallelFx ( http://www.techheadbrothers.com/Articles.aspx/decouverte-parallelfx ).
Les soupçons en questions sont amené notamment par ce débat ( (en) http://channel9.msdn.com/posts/Charles/Anders-Hejlsberg-and-Guy-Steele-Concurrency-and-Language-Design/ ).
Un article expliquant brièvement la concurrence (exemples en java) : ( http://blog.xebia.fr/2008/08/13/programmation-concurrentielle-notions-fondamentales/).
Articles Wikipedia sur La programmation concurrente et Les mémoire transactionnelles logicielles