Un système de sessions en Piccolo

Nous considérons la modélisation d’un système de sessions du listing 3.4.

Dans cet exemple, un serveur permet d’établir des connexions avec des clients, ainsi que de les rediriger (de manière transparente pour le client) vers un service ou un autre, selon que ce client est connu du serveur ou s’il consulte le service en tant qu’invité. Deux services sont donc modélisés : un service "client" et un service "guest". Le serveur délègue la gestion du service à une tâche créée dynamiquement : un processus exécutant .

Il s’agit là d’une modélisation du serveur, et non d’un programme Piccolo à part entière. À ce titre, le système est ouvert, et les clients ne sont pas modélisés, puisque faisant partie de l’environnement avec lequel pourrait communiquer un serveur implantant cette spécification, via le canal .

3.3.2 Problématiques

Systèmes finitaires Il s’agit là du cas que nous avons déjà largement évoqué. S’il est

pos-sible de construire un espace d’états fini pour représenter le comportement d’un système concurrent, il est possible de l’utiliser pour construire un modèle représentant uniquement les manipulations de ressources, puisqu’alors le nombre de ressources nécessaires est forcément fini lui aussi. C’est l’approche que nous avons adopté dans notre travail.

Systèmes à contrôle infini et à ressources finies Nous considérons ici le cas des systèmes à

contrôle infini, comme, par exemple, notre serveur présenté ci-dessus. On constate en effet que la définition , qui s’appelle récursivement elle-même, crée à chaque réception sur le canal un nouveau processus exécutant la définition . Le présent serveur peut donc allouer, selon les requêtes des clients, un nombre arbitrairement grand de tâches, sans que l’exécution des précédentes soient terminées.

Concernant les ressources dynamiques, les seules ressources allouées ici le sont durant l’initialisation du serveur. De plus, on constate assez aisément dans cet exemple que le nombre de ces ressources est fini (il y a en fait trois canaux de communication alloués avec le construc-teurnew).

40 Motivations

Listing 3.4 – Modélisation d’un système de sessions

def Server ( socket : chan<chan< s t r i n g > > ,

s e r v i c e 1 : chan< s t r i n g > , s e r v i c e 2 : chan< s t r i n g >) = socket ? (conn ) ,

[ IS_A_REGISTERED_CLIENT ( conn ) ] tau ,

spawn { ServerTask ( conn , s e r v i c e 1 ) } ,

Server ( socket , service1 , s e r v i c e 2 ) + [ true ] tau ,

spawn { ServerTask ( conn , s e r v i c e 2 ) } ,

Server ( socket , service1 , s e r v i c e 2 )

def ServerTask ( c l i e n t : chan< s t r i n g > , s e r v i c e : chan< s t r i n g >) =

c l i e n t ? ( req ) , s e r v i c e ! req , s e r v i c e ? ( resp ) , c l i e n t ! ( resp ) ,

ServerTask ( c l i e n t , s e r v i c e )

def Serv ice ( serv : chan< s t r i n g >) =

serv ? ( request ) ,

[ request = REQ₁] tau , serv !RESP₁, Service ( serv ) + [ request = REQ₂] tau , serv !RESP₂, Service ( serv ) + . . .

+ [ request = REQ_n] tau , serv !RESP_n, Service ( serv )

def Main ( ) =

new ( c l i e n t S e r v i c e : chan< s t r i n g > ) , new ( guestService : chan< s t r i n g ) , spawn { Serv ice ( c l i e n t S e r v i c e ) } , spawn { Serv ice ( guessService ) } ,

new ( socket : chan<chan< s t r i n g > >) ,

Server ( socket , c l i e n t S e r v i c e , guestService ) ,

Nous sommes donc face à un système au contrôle infini, difficile à étudier dans son com-portement, mais également à uniquement trois ressources dynamiques, dont on souhaiterait étudier les utilisations. Il s’agit là d’une problématique qui nous semble intéressante : celle d’atteindre une abstraction pour laquelle il ne serait, dans certains cas, pas obligatoire de pas-ser par la représentation du comportement complet d’un système concurrent pour représenter les utilisations des ressources. Cela laisserait entrevoir l’étude des ressources dynamiques pour des systèmes à contrôle infini et à ressources finies de la même façon que pour un système finitaire, en s’abstrayant du caractère infini du comportement de tels systèmes.

Deuxième partie

C

H AP ITRE

4

ν-AUTOMATES

A

FIN D’ABORDERsous un angle technique les problématiques introduites, il est nécessaire de se munir d’une bonne abstraction pour raisonner sur les ressources dynamiques ma-nipulées par un système. Pour l’analyse de l’utilisation des ressources, quelle que soit la nature de cette utilisation, seuls les événements élémentaires de ressources feront partie de cette abs-traction : les allocations, les utilisations, ainsi que les libérations des ressources dynamiques. Dans un contexte concurrent, avec des sémantiques d’entrelacements d’actions atomiques, il convient de considérer tous les chemins d’exécutions possibles d’un système, dans le but d’en extraire le pire scénario quant à la consommation des ressources qu’il nécessite. Ce constat nous conduit naturellement aux formalismes des langages et des automates. Un automate permet effectivement l’expression de branchements et de choix dans un système, et le langage qu’il reconnaît représente l’ensemble exhaustif des traces d’exécution du système. De plus, la représentation d’un automate sous la forme d’un graphe est une structure de choix pour l’établissement d’algorithmes.

Nous manipulons dans ce chapitre des langages à alphabets infinis : puisqu’il n’est pas possible de prévoir à l’avance l’ensemble des allocations dynamiques nécessaires au bon déroulement d’un système, les symboles des mots du langage sont issus d’un ensemble infini de noms purs. Lesν-automates, reconnaissant des ν-langages, permettent ainsi de raisonner

sur les ressources manipulées par un système concret, de manière à analyser par la suite précisément ce modèle constitué exclusivement d’allocations, d’utilisations et de libérations de ressources. La spécificité principale desν-automates réside dans le fait qu’ils font apparaître

explicitement les allocations et les libérations des ressources, permettant ainsi la délimitation précise des durées de vie desdites ressources. Nous développons dans ce chapitre les propriétés et possibilités qui découlent entre autres de cette caractéristique.

Dans une première section, nous introduisons les programmes de ressources, définis selon une grammaire inspirée des expressions rationnelles, et spécialisés dans la manipulation des

44 ν-automates

ressources dynamiques. La section suivante est dédiée à la formalisation desν-automates finis, machines reconnaissant les traces des programmes de ressources. Ce premier modèle

d’automates est général, dans la mesure où il présente le moins de contraintes possibles quant aux utilisations et aux réallocations des ressources qu’il autorise. Unν-automate fini

autorise une variable de ressources à être associée à un nombre non borné de noms purs, et ainsi de modéliser différents phénomènes de fraîcheur. Nous introduisons ensuite les ν-automates finis élémentaires, qui limitent les réallocations successives d’une même ressource.

Ils restreignent ainsi à un nombre fini la quantité d’identités nécessaires à l’expression des langages qu’ils reconnaissent. Cette restriction permet des analyses quantitatives précises. La troisième section est consacrée à la présentation de ces analyses de ressources. Le présent chapitre se termine par une discussion à propos de la comparaison entre lesν-automates et

plusieurs autres formalismes du même type présents dans la littérature. En particulier, on compare formellement l’expressivité desν-automates avec celle des automates à mémoire

finie [Kaminski et Francez, 1994], représentants emblématiques des automates reconnaissant des langages définis depuis des alphabets infinis.

4.1 Profils de ressources

Nos analyses quantitatives de ressources consistent à synthétiser une borne minimale de ressources consommées dans le pire cas d’exécution d’un système. Pour considérer ce pire cas, il est nécessaire de considérer la totalité des traces d’utilisation de ressources dynamiques allouées par le système. Ces traces sont des suites d’occurrences d’utilisations de ressources. L’aspect fondamental de ce type d’ensemble est qu’il fait intervenir des symboles dont les identités ne peuvent être connues à l’avance. On manipule donc un ensemble infini de noms

purs, ce qui permet de disposer d’autant d’identités de ressources fraîches que nécessaires

tout au long de l’exécution d’un système.

On illustre le choix de ces noms purs frais, issus d’un ensemble infini V contenant les nomsν₁,ν₂, . . ., à l’aide de petits systèmes séquentiels abstraits. D’abord, un système utilisant deux fois à la suite une même ressource, génère une trace de ressources de la forme :

νiνi, avecνi∈ V .

En comparaison avec cet exemple, un système allouant deux ressources X et Y puis utili-sant dans cet ordre X , Y , puis à nouveau X avant de se terminer, requiert une distinction entre les deux identités manipulées. Cette distinction doit apparaître dans les traces de ressources du système, qui auront alors la forme suivante :

νiνjνi, avecνi,νj∈ V et i = j.

Les traces considérées ici ne contiennent que les marques des utilisations des ressources manipulées par un système. Tandis que nous traitons des ressources dynamiques, allouées et libérées donc tout au long de la génération d’une telle trace, les seuls événements utiles à une analyse quantitative des ressources à partir des traces sont en fait les utilisations. C’est en effet durant ce type d’événements qu’un nom, une identité (νiouνjdans les exemples ci-dessus),

4.1. Profils de ressources 45

Ressource X , Y , . . .

Événement de ressources R

::= alloc(X ) Allocation de la ressource X

| use(X ) Utilisation de la ressource X

| free(X ) Libération de la ressource X

Programme P

::= end Fin du programme

| atomic

R1, . . . , Rn

.P Séquence atomique d’événements de ressources

| P + P Choix non-déterministe

| P^∗ Répétition (étoile de Kleene)

FIGURE4.1 – Syntaxe des programmes de ressources

est concrètement attribué à une variable de ressource (X ou Y dans l’exemple ci-dessus). Ce nom est alors celui qui apparaît dans les traces du système, en tant qu’instanciation de la variable de ressource du système concret modélisé qu’il représente.

Les allocations et les libérations n’apparaissent donc pas explicitement dans les traces générées. Toutefois, comme nous le montrons dans de prochains exemples, ils dirigent d’une certaine manière le phénomène d’attribution d’identités aux ressources, en permettant par exemple l’attribution de plusieurs identités à une même variable. Ces types d’événements ont donc également leur importance, et contribuent notamment à la grande expressivité de notre modèle.

Afin de raisonner sur les traces produites par les systèmes que nous souhaitons étudier, nous introduisons tout d’abord les programmes de ressources. Ils représentent des séquences de manipulations de ressources dynamiques de systèmes concrets. La sémantique de ces programmes correspond à des traces de ressources, que nous formalisons sous la forme de

ν-langages, langages formels dont les mots sont définis sur un alphabet infini de noms purs,

et reconnus par lesν-automates (dans le cas où ils ont été produits depuis un programme de

ressources).

Dans le document Analyse de ressources pour les systèmes concurrents dynamiques (Page 46-52)