En dehors de l’estimation et de l’optimisation de la quantité de ressources dynamiques utilisées par un système, cette consommation peut en fait refléter directement des propriétés importantes du système en question. Nous illustrons ce point à l’aide du célèbre problème du dîner des philosophes [Dijkstra, 1971].
3.2.1 Le dîner des philosophes
Présentation Le problème du dîner des philosophes est un problème classique de
concur-rence, qui illustre notamment la synchronisation entre processus. L’énoncé résumé en est le suivant : des philosophes se retrouvent autour d’une table sur laquelle se trouve entre chaque couple de philosophes une fourchette. Les philosophes doivent se saisir des deux fourchettes qui les entourent pour pouvoir manger, et reposent de temps à autres les fourchettes pour faire une pause dans leur repas et méditer.
Implémentation Pour cette implémentation (listing 3.3), nous choisissons de ne pas
dé-tailler le processus de mise en place des différents processus en jeu, puisque nous souhaitons nous concentrer en particulier sur les canaux de communication durant l’exécution du cœur du problème. Certaines libertés de notation sont donc prises dans la définition du .
Le reste du programme est directement calqué depuis la spécification du problème. Un processus représentant un philosophe exécute soit (s’il entreprend de manger), soit (s’il entreprend de reposer les couverts sur la table). Un ensemble de processus exécutant récupère des tickets de la part des philosophes qui mangent, et leur restitue ensuite.
3.2.2 Abstraction et propriétés du système
Nous avons évoqué dans les cas d’étude précédents la multiplicité des ressources dyna-miques à gérer dans un cadre de programmation concurrente et parallèle. Dans ce nouvel exemple, les ressources que nous considérons sont uniquement des canaux de communica-tion. Un second niveau de paramétrage est toutefois possible : on peut souhaiter sélectionner un certain type de canaux à observer. Ici, par exemple, nous considérerons uniquement les canaux générés dynamiquement dans la définition : les tickets distribués aux philosophes lorsqu’ils passent à table. La seule observation de ces ressources nous permet alors, non seulement de définir une borne de ressources optimale pour une sous-partie du système, mais surtout d’en déduire une propriété fondamentale du problème : en supposant que la réutilisation des tickets distribués est optimale, il ne devrait jamais y avoir besoin de plus de n/2 tickets nécessaires pour un problème à n philosophes. L’analyse des ressources n’apporte alors plus seulement des propriétés techniques sur la plateforme d’exécution, mais également des propriétés sémantiques sur le modèle implémenté, voire des garanties sur cette implémentation, puisque l’on peut choisir d’analyser les pire-cas. En analysant tous les chemins possibles d’exécution, s’il n’y a besoin que d’au plus n/2 tickets, cette implémentation
3.2. Propriétés sur les systèmes et les programmes 37
Listing 3.3 – Une implémentation du dîner des philosophes
def TicketGenerator ( gen : chan<chan<unit >>) = new ( t i c k e t : chan<unit > ) ,
gen ! t i c k e t ,
TicketGenerator ( gen )
def Philo ( gen : chan<chan<unit > > , control : chan<chan<unit > > ,
l e f t : chan<unit > , r i g h t : chan<unit >) = gen ? ( t i c k e t ) ,
( l e f t ? ( ) , r i g h t ? ( ) control ! t i c k e t ,
PhiloBis ( gen , control , l e f t , r i g h t ) + r i g h t ? ( ) , l e f t ? ( ) ,
control ! t i c k e t ,
PhiloBis ( gen , control , l e f t , r i g h t ) )
def PhiloBis ( gen : chan<chan<unit > > , control : chan<chan<unit > > ,
l e f t : chan<unit > , r i g h t :chan<unit >) = control ? ( x ) ,
( l e f t ! ( ) , r i g h t ! ( ) ,
Philo ( gen , control , l e f t , r i g h t ) + r i g h t ! ( ) , l e f t ! ( ) ,
Philo ( gen , control , l e f t , r i g h t ) )
def Fork ( f o r k : chan<unit >) =
fo r k ! ( ) , fo r k ? ( ) , Fork ( fo r k )
def C o n t r o l l e r ( control : chan<chan<unit >>) =
control ? ( t i c k e t ) , control ! t i c k e t , C o n t r o l l e r ( control )
def Main ( ) =
new ( gen : chan<chan<unit > >) , new ( fork1 : chan<unit > ) ,
. . .
new ( forkn : chan<unit > ) ,
Fork ( fork1 ) | | . . . | | Fork ( forkn ) | | Philo ( gen , control , fork1 , fork2 ) | |
. . . | |
Philo ( gen , control , forkn , fork1 ) | | TicketGenerator ( gen ) | |
38 Motivations
présente bien la garantie qu’il n’y a jamais plus de n/2 philosophes qui mangent en même temps.
3.2.3 Profils de ressources
Une généralisation de ce principe de propriété de ressources serait de considérer non plus les propriétés de ressources indépendamment les unes des autres, mais plutôt de considérer un objet représentant à lui seul le profil du comportement général d’un système ou d’un programme vis-à-vis de ses ressources. Nous discutons de ce point à l’aide d’un exemple informel : il s’agit de différentes implémentations du protocole de transfert cellulaire utilisé dans les communications mobiles GSM, issus de l’outil HAL implantant la vérification par les HD-automates, et dont les spécifications initiales sont tirées de [Orava et Parrow, 1992]. Cet exemple met en œuvre quatre entités :
— une station mobile, embarquée dans une voiture en déplacement entre deux zones géographiques différentes et qui offre des services à l’utilisateur,
— un centre de contrôle de radiocommunications qui gère les communications, et en particulier celles des deux zones géographiques dans laquelle se trouve la voiture, — deux bases stationnaires, une dans chaque zone, qui permettent la communication
entre la station mobile et le centre de contrôle.
Les actions observables correspondent aux messages en provenance d’un environnement extérieur parvenant à l’utilisateur via le centre de contrôle et les bases stationnaires, ainsi que les messages émis par l’utilisateur vers l’environnement, par les mêmes intermédiaires. Il illustre également parfaitement le principe de mobilité dans les systèmes concurrents, les canaux de communication étant en fait transférés d’une base à l’autre par le centre de contrôle afin de permettre une communication en continu lors du changement de zone géographique par l’utilisateur.
À l’aide de l’une des premières versions du prototype réalisé dans le cadre de cette thèse, nous avons construit l’espace d’états et profilé un graphe des événements de ressources des modélisations enπ-calcul de ce problème. La taille des divers objets obtenus figurent dans le
tableau ci-dessous [Deharbe et Peschanski, 2014].
Modèle Système de transitions étiquetées Graphe de ressources
GSM 489 56
GSMbuff 164 56
GSMfull 2183 56
Bien qu’elles respectent toutes la spécification initiale du protocole de transfert cellulaire, ces différentes mises en œuvre ne génèrent pas le même espace d’états. Cependant, les tailles de graphes d’événements de ressources sont quant à eux très révélateurs : ils sont en fait identiques pour les trois systèmes. Bien que le comportement soit différent d’une implémentation à une autre, les trois systèmes respectant la même spécification font le même