0 200 400 600 800 1000 1200 1400 1600 3 5 10
Temps (ms) pour 1000 synchro.
Nombre de processus distants BarriŁre de synchronisation distribuØe LNT-DLC-old
LNT-DLC-latest
Figure 6.2 – Gain en performances de notre protocole par rapport à la version de Parrow et Sjödin.
6.2 Le dîner des philosophes
Notre deuxième expérience consiste à évaluer les performances des implémentations gé-nérées pour le problèmes classique du dîner des philosophes [Dij71]. Cette expérience est l’occasion d’illustrer d’une part comment le rendez-vous multiple peut simplifier la pro-grammation concurrente, et d’autre part les performances atteintes pour un système où plusieurs rendez-vous peuvent avoir lieu de manière indépendante.
Nous rappelons brièvement l’énoncé du problème du dîner des philosophes. Plusieurs phi-losophes mangent autour d’une table ronde. Il existe une fourchette entre chaque paire de philosophes voisins de table. Un philosophe tour à tour pense et mange, et il a besoin de la fourchette à sa gauche et de celle à sa droite pour pouvoir manger. Une fourchette ne peut être utilisée que par un seul philosophe à la fois. Le problème consiste à organiser la prise de fourchette entre philosophes, afin que tous puissent manger.
6.2.1 Ressources partagées et rendez-vous multiple
Le dîner des philosophes est une représentation des problèmes d’accès à des ressources partagées (les fourchettes) par plusieurs processus (les philosophes). C’est un problème classique de la programmation concurrente. Parmi les solutions à ce problème, celle pro-posée par Dijkstra consiste à définir un ordre sur les fourchettes, et à imposer à chaque philosophe de prendre les fourchettes dans l’ordre. Nous avons déjà évoqué cette solution à la section 1.4.2. Une autre solution possible est de faire intervenir un serveur qui restreint l’accès aux fourchettes à un seul philosophe à la fois. En pratique, cette restriction peut être imposée par une construction qui assure l’exclusion mutuelle entre les processus, telle qu’un “mutex” par exemple.
Toutes ces solutions font l’hypothèse qu’un philosophe n’interagit qu’avec une seule four-chette à la fois. Considérons maintenant que nous avons le rendez-vous multiple à dispo-sition : la prise de fourchettes peut être implémentée en un rendez-vous à trois entre un philosophe et les deux fourchettes à ses côtés. Le rendez-vous multiple garantit que, si l’action a lieu, alors les deux fourchettes ont été prises.
Nous avons ainsi utilisé le rendez-vous multiple pour implémenter un dîner de philosophes en LNT. Le comportement d’un philosophe consiste à penser, à prendre ses fourchettes (action sur la porte TAKE), à manger, puis à reposer ses fourchettes (action sur la porte RELEASE) :
processPHILO [TAKE, RELEASE: none]is loop −− think TAKE; −− eat RELEASE end loop end process
Le comportement d’une fourchette consiste à être prise par le philosophe à sa gauche ou bien par celui à sa droite, puis par être reposée par le philosophe qui l’a prise :
processFORK [LEFT_TAKE, LEFT_RELEASE, RIGHT_TAKE, RIGHT_RELEASE: none]is loop select LEFT_TAKE; LEFT_RELEASE [] RIGHT_TAKE; RIGHT_RELEASE end select end loop end process
Nous pouvons ensuite définir un dîner de philosophes grâce à une composition parallèle de processus philosophes et fourchettes. Par exemple, un dîner à trois philosophes est obtenu avec la composition parallèle suivante :
par TAKE_0, RELEASE_0, TAKE_1, RELEASE_1, TAKE_2, RELEASE_2in par
PHILO [TAKE_0, RELEASE_0]
| | PHILO [TAKE_1, RELEASE_1]
| | PHILO [TAKE_2, RELEASE_2]
end par | |
par
TAKE_0, RELEASE_0, TAKE_1, RELEASE_1−>
FORK [TAKE_0, RELEASE_0, TAKE_1, RELEASE_1]
| | TAKE_1, RELEASE_1, TAKE_2, RELEASE_2−>
6.2. Le dîner des philosophes 133
| | TAKE_2, RELEASE_2, TAKE_0, RELEASE_0−>
FORK [TAKE_2, RELEASE_2, TAKE_0, RELEASE_0]
end par end par
Le rendez-vous multiple facilite l’implémentation du dîner des philosophes : nous n’avons pas besoin de construction de mutex, ni d’avoir à préciser un ordre sur les fourchettes. Le rendez-vous multiple permet d’assurer directement l’exclusion mutuelle des philosophes voisins, et le choix non déterministe au niveau d’une fourchette la rend accessible aux deux philosophes l’entourant. Au niveau de l’implémentation générée, le rendez-vous multiple se traduit effectivement par un protocole de synchronisation entre processus. Toutefois, au niveau de la spécification, le rendez-vous multiple offre une abstraction de plus haut niveau que des interactions limitées à deux entités.
6.2.2 Mesures de performances
Nous avons produit un modèle LNT pour plusieurs configurations de dîner de philosophes. Nous avons ensuite utilisé DLC pour obtenir des implémentations distribuées. La figure 6.3 illustre les performances atteintes pour les différentes configurations.
0 1 2 3 4 5 2k 4k 6k 8k 10k DurØe d’exØcution
Nombre d’actions, en milliers 3 philosophes
5 philosophes 10 philosophes
Figure 6.3 – Durée nécessaire pour réaliser un certain nombre de rendez-vous, pour plu-sieurs configuration. Plus il y a de philosophes, plus le nombre d’actions qui peuvent être réalisées en parallèle augmente, et plus la durée d’exécution est courte.
Nous avons mesuré la durée nécessaire pour réaliser un certain nombre d’actions. Toutes les actions sont des rendez-vous à trois entre un philosophe et une paire de fourchettes, qui traduisent une prise ou un relâchement de fourchettes. Nous avons utilisé une option de l’implémentation générée par DLC qui indique au nœud central d’arrêter l’exécution après un certain nombre d’actions réalisées dans le système, et de retourner le temps d’exécution
du système1. Ces mesures ont été réalisées sur le cluster “edel” du site de Grenoble de Grid5000. Pour chaque configuration, nous avons utilisé autant de machines qu’il y a de philosophes, et les autres programmes (fourchettes et portes) ont été distribués de manière équitable sur ces machines.
On remarque tout d’abord que lorsque le nombre de philosophes augmente, la durée néces-saire pour réaliser un certain nombre d’actions diminue. Cela illustre que les rendez-vous qui peuvent avoir lieu de manière concurrente sont effectivement réalisés en parallèle. La configuration à 10 philosophes effectue ainsi 10000 actions en à peine plus d’une seconde. La configuration à trois philosophes est particulièrement intéressante : tous les philosophes sont voisins entre eux, et lorsqu’un philosophe mange, aucun autre philosophe ne peut manger. Toutes les actions de cette configuration sont donc effectuées en séquence. L’im-plémentation générée requiert environ une seconde pour réaliser 2000 actions. Cette perfor-mance est moins bonne que celle obtenue pour la synchronisation de trois processus sur la barrière de synchronisation de la section 6.1. Cela s’explique par le choix non déterministe du comportement des fourchettes, qui interdit un auto-verrouillage des fourchettes pour les actions sur les portes TAKE. On note tout de même que l’implémentation réalise plus d’un millier d’actions en séquence par seconde.