Session 5 Modèles des systèmes réactifs et parallèles

Transcription

Méthodes formelles
de développement
(5/9)
Session 5
Modèles des systèmes
réactifs et parallèles
Hubert Garavel
Frédéric Lang
Pascal Raymond
Wendelin Serwe
CNAM Grenoble – PR – 19 mars 2010
Méthodes formelles de développement
< 1 / 61 >
< 2 / 61 >
Introduction
But de cette session
aborder un domaine d’application où la sûreté de
fonctionnement est essentielle : systèmes dynamiques,
temps-réel, parallèles
besoin de garantie de qualité/sûreté, d’où utilisation de
méthodes formelles
dans cette section : après avoir vu les modèles classiques
des systèmes transformationnels, on va voir comment
prendre en compte le(s) parallélismes(s).
Introduction
< 3 / 61 >
Partie I
Introduction
Pourquoi « systèmes réactifs » ?
Introduction
< 4 / 61 >
Pourquoi « système » ?
Pourquoi « réactif » ?
(et pas « programme ») ?
Par opposition à « transformationnel » (cf. session 4),
programmes classiques, avec une donnée et un résultat
final (e.g. compilateur).
Maintiennent une interaction permanente avec un
environnement,
interactif : l’environnement est typiquement un humain, le
système réagit à sa vitesse propre (interface HM, browser),
réactifs (temps-réel) : l’environnement est typiquement le
monde physique, c’est lui qui impose le rythme.
applications souvent réparties, parallèles,
composite : logiciel applicatif/logiciel de base/matériel,
cas limites : purement matériel (circuit), purement
algorithmique (protocole de communication).
On s’intéresse au réactif dur : c’est le domaine des
applications critiques (contrôle/commande, embarqué).
< 6 / 61 >
< 7 / 61 >
Introduction
Introduction
Caractéristiques générales
Quelques questions annexes ...
Dynamique :
On n’attend pas un « résultat » : la fonctionnalité est dans le
fonctionnement lui-même, le comportement,
prise en compte de la (ou d’une) notion de temps
indispensable.
Parallélisme :
il peut être logique/simulé (thread/process), temps partagé,
protection des ressources partagées,
ou réel (distribution), communication asynchrone,
cohérence/fraı̂cheur des données.
Introduction
< 8 / 61 >
« parallèle » implique-t-il « réactif » ?
Non : algorithmique parallèle pour des problèmes
transformationnels (efficacité, e.g. grilles de calcul, pipeline
etc)
« réactif » implique-t-il « parallèle » ?
Pas forcément pour des systèmes très simples, mais
quasiment toujours d’un point de vue conceptuel
(parallélisme d’exécution vs parallélisme de description)
Enfin, la frontière transformationnel/réactif est ténue : ex.
décodage vidéo fichier à fichier vs flux à flux...
< 9 / 61 >
Systèmes de transitions
Les grandes lignes de cette session
Un système parallèle = des systèmes séquentiels « qui
tournent en même temps ».
Un système séquentiel est modélisé par un système de
transitions.
Problème : définir un modèle du comportement global
(parallèle) à partir des modèles des composants
séquentiels.
< 10 / 61 >
Graphe de contrôle
< 11 / 61 >
Un programme simple booléen
L’état d’un système en cours d’exécution est la valeur de
toutes les variables/ressources qui influencent le
comportement futur.
Une transition est le passage d’un état à un autre.
En particulier, pour les programmes impératifs séquentiels :
toutes les variables du programme, plus le « point de contrôle
courant ».
Rappels : notion d’état et de transition
Partie II
< 13 / 61 >
X, Y : bool = false;
begin
(1)
while cont() do
(2)
X := not X ;
(3)
Y := (X == Y);
(4)
end
(5)
end
not cont() ?
1
cont() ?
2
5
cont() ?
not cont() ?
X := not X
3
Y := (X == Y)
4
< 14 / 61 >
Remarques
Expansion des variables
les transitions sont étiquetées par des labels, pas de
sémantique (pour l’instant)
on peut aller plus loin : les valeurs des variables influencent
aussi le comportement
< 15 / 61 >
1-FF
2-FF 2-TF 2-FT 2-TT
3-TF 3-FF 3-TT 3-FT
4-TF 4-FT 4-TT 4-FF
5-TF 5-FT 5-TT 5-FF
< 17 / 61 >
Graphe de contrôle + variables
Variables à domaines finis (et petits)
Le graphe est fini : on reboucle nécessairement
Exploration exhaustive possible
Le graphe est un modèle exact des comportements
Démarche possible pour des variables à domaine fini (et
pas trop gros)
< 18 / 61 >
A, B : bool := true ;
X : integer range 1..5 := 1 ;
begin
(1)
while X < 5 loop
(2)
A := B and pair(X) ;
(3)
B := A or impair(X) ;
(4)
X := X+1 ;
(5)
end loop ;
(6)
end
A, B : bool := true ;
X : integer range 1..5 := 1 ;
begin
(1)
while X < 5 loop
(2)
A := B and pair(X) ;
(3)
B := A or impair(X) ;
(4)
X := X+1 ;
(5)
end loop ;
(6)
end
X>=5 ?
1
x<5 ?
2
X<5 ?
A := B and pair(X)
3
B :=A or impair(X)
6
X>=5 ?
4
X :=X+1
5
Expansion des variables
X, Y : bool = false;
begin
(1)
while cont() do
(2)
X := not X ;
(3)
Y := (X == Y);
(4)
end
(5)
end
Remarques
< 19 / 61 >
Automates interprétés
Cas général
1.TT1
5.TT3
2.TT1
2.TT3
3.FT1
3.FT3
4.FT1
4.FT3
5.FT2
5.FT4
2.FT2
2.FT4
3.TT2
3.TT4
4.TT2
4.TT4
5.TT5
6.TT5
< 20 / 61 >
Programmes avec :
variables de types quelconques,
des entrées/sorties,
qui ne terminent pas forcément ...
... le graphe des états est « virtuellement infini »
(tout du moins très gros)
Solution : automates interprétés
structure de contrôle finie (automate)
labels interprétés, avec une sémantique ad hoc
(selon les besoins)
< 22 / 61 >
Automates conditions/actions
Conclusion sur les automates interprétés
un exemple d’automates interprétés classique (et utile),
les labels sont des conditions ou des actions,
adéquat pour modéliser les programmes séquentiels.
X−−
>−−
5−
?→q 0 −−
X−−
:=
−−X+1
−−→q 00
exemple : q −−
X > 5 / X := X+1 00
résumé en : q −−−−−−−−−−−−−−−−→q
Remarque : formalisme très riche, même puissance
d’expression que les machines de Turing
< 23 / 61 >
Modélisation du parallélisme
automates finis (partie simple)
+ labels éventuellement très « riches » (partie complexe)
les labels cond/act sont un exemple : on peut en définir
d’autres pour refléter d’autres besoins ...
on va voir d’autres sortes de labels pour traiter le
parallélisme
< 24 / 61 >
Notion de produit d’automate
Qu’est-ce que le parallélisme ?
Partie III
Intuitivement : plusieurs programmes fonctionnent « en
même temps »
Prenons le cas de deux programmes (P1 et P2).
But : soient M1 et M2 les modèles de P1 et P2 (automates),
comment construire un modèle M qui représente fidèlement
le fonctionnement parallèle de P1 et P2 ?
< 25 / 61 >
Notion de produit d’automate
A1
B1
c
A2
β
B2
A2 B1
?
Le produit asynchrone
Modélise fidèlement les cas multi-processus, multi-threads
Les deux processus évoluent à leurs rythmes propres
En bref : soit c’est le 1 qui avance, soit c’est le 2 ...
A1 B2
?
?
< 27 / 61 >
?
?
α
a
b
A1 B1
?
C’est essentiellement un produit cartésien ...
γ
A2 B2
?
États : pas de problème, couples (Ai , Bj )
Transitions ? ? ? ?
Pas de solution universelle : on va voir deux cas classiques
< 28 / 61 >
< 30 / 61 >
Le produit asynchrone (exemple)
B1
A1 B1
a
γ
c
A2 B1
β
A2
B2
b
b
le produit représente fidèlement le comportement, à
condition que la granularité des opérations soit réaliste
Exemple :
α
c
α
a
Attention à l’atomicité
γ
γ
A1
β
α a
A1 B2
deux tâches qui partagent des variables,
x vaut 1, y vaut 0,
la tâche 1 s’apprête à exécuter x := 2*x + 1,
la tâche 2 s’apprête à exécuter y := x
c
β
A2 B2
b
< 31 / 61 >
A1
x=1,y=0
A1 B1
x=3,y=0
A2 B1
y :=x
x :=2*x+1
y :=x
y :=x
x=1,y=1
A1 B2
x :=2*x+1
x=3,y=3
A2 B2
B2
A2
< 32 / 61 >
Attention à l’atomicité (suite)
x :=2*x+1
B1
x=1,y=0
x=3,y=1
A2 B2
x := 2*x + 1 est une instruction de haut niveau (C, java)
en langage machine, elle devient (par exemple)
shift x ; incr x
tandis que y := x devient mov x y
Ça ne donne pas le même modèle !
... mais est-ce bien réaliste ?
< 33 / 61 >
< 34 / 61 >
Attention à l’atomicité (conclusion)
Seule les instructions machine sont atomiques
x=1,y=0
x=1,y=0
A1
B1
x=1,y=1
x=2,y=0
shift x
A2
mov x y
shift x
mov x y
incr x
A3
B2
incr x
mov x y
x=3,y=0
x=2,y=2
mov x y
x=3,y=3
incr x
x=3,y=2
shift x
x=2,y=1
incr x
x=3,y=1
Pour pouvoir faire des produits réalistes, il faut toujours se
poser la question de la granularité :
est-ce que les transitions des composants sont bien
atomiques ?
C’est LE PROBLÈME de la programmation parallèle
asynchrone : chercher à garantir l’atomicité d’un bout de
code.
Lié au problème de la cohérence de données.
nouvelle configuration, impossible avant !
< 35 / 61 >
< 36 / 61 >
Exemple de l’heure
Exemple de l’heure (suite)
if (m == 59) h = (h+1) mod 24 ;(* incr h *)
m = (m+1) mod 60 ;
(* incr m *)
< 37 / 61 >
< 39 / 61 >
h=00,m=00
< 38 / 61 >
d0 := false ;
loop
<section non critique>
a : d0 := true ;
b : tour := 0 ;
c : wait(d1=false or tour=1) ;
d* : <section critique>
e : d0 := false ;
d1 := false ;
loop
<section non critique>
A : d1 := true ;
B : tour := 1 ;
C : wait(d0=false or tour=0) ;
D* : <section critique>
E : d1 := false ;
Problèmes de modélisation, granularité ?
on suppose que l’affectation et le test sont atomiques
inutile de “trop détailler” (intérêt de l’indéterminisme)
< 40 / 61 >
Algorithme de Peterson (le bon produit)
A
d0 :=true
d1 :=true
b
asynchrone, pas de simultanéité (pour la granularité
considérée)
expansion des variables partagées pour plus de précision ...
B
tour :=0
tour :=1
c
(d1=false or tour=1) ?
d0 :=false
incr m
print
Algorithme de Peterson (les modèles)
a
h=00,m=59
Algorithme de Peterson (le programme)
en résumé : quand on programme « parallèle », se pose le
problème de l’atomicité des actions, très important lors des
accès aux ressources partagées
c’est ce qu’on appelle l’exclusion mutuelle
à un niveau suffisamment bas, il y a forcément exclusion
mutuelle (au niveau matériel, impossible d’écrire et/ou lire
une même case mémoire)
mais ce n’est pas suffisant pour les programmes de haut
niveau (cf. l’exemple précédent)
problème classique : peut-on programmer l’exclusion
mutuelle ?
Un exemple classique : algorithme de Peterson
print
Notion d’exclusion mutuelle
il est incohérent
h=00,m=59
h=00,m=00
print
h=00,m=00
Mais pendant tout ce temps,
incr h
incr m
une tâche indépendante, plus rapide, qui lit et affiche
l’heure (qu’on notera l’action print),
état global = valeur de h, de m et aussi afficheur.
Tôt ou tard, l’affichage sera correct ...
h=23,m=59
deux variables : h(eure) et m(inute)
une tâche activée par une horloge temps-réel toute les
minutes, qui réalise l’action non atomique :
d
Au final, un état produit est un quintuplet :
(contrôle 1, contrôle 2, d0, d1, tour)
C
(d0=false or tour=0) ?
d1 :=false
D
< 41 / 61 >
< 42 / 61 >
Algorithme de Peterson (résultat)
Algorithme de Peterson (résultat)
aA FFX
bA TFX
cA TF0
dA TF0
aB FTX
bB TTX
cB TT0
dB TT0
eB TT0
cC TT1
dC TT1
eC TT1
aC FT1
bC TT1
aD FT1
bD TT1
cD TT0
aE FT1
bE TT1
cE TT1
eA TF0
cC TT0
Remarque :
les OS proposent des librairies de (plus) haut niveau pour
programmer l’exclusion mutuelle, par ex. mutex,
sémaphores
tous sont basés sur le même principe :
certaines opérations sont garanties
« matériellement »exclusive (affectation, test-and-set)
on s’en sert pour bloquer l’exécution d’une tâche qui voudrait
accéder à une zone « occupée »
On a bien l’exclusion mutuelle :
“dD” inaccessible
ça garantit que ce que fait la tâche 1 dans d (resp. la tâche
2 dans D) est « atomique »
< 43 / 61 >
Un exemple avec des mutex
Deux grandes familles :
multi-threads (ou processus légers) :
partagent la même mémoire,
fonctionnent en temps partagé (mono-processeur), ou en
parallèle physique (multi-processeurs, multi-cœur) (c’est
transparent pour le programmeur)
les accès concurrents doivent être protégés (mutex,
sémaphores etc.)
thread1(){
thread2(){
while(true) {
while(true) {
sleep ms(60000) ;
sleep ms(1000) ;
take mutex(key) ;
take mutex(key) ;
if (m = 59) h = (h+1) mod 24 ;
print hour(h, m) ;
m = (m+1) mod 60 ;
release mutex(key) ;
release mutex(key) ;
}
}
}
}
multi-processus :
ont leurs mémoires propres
tout échange de données se fait via l’OS, qui garantit
l’intégrité
< 45 / 61 >
Communication multi-processus
Le produit synchronisé
Très similaire au cas asynchrone : modélise des tâches
essentiellement asynchrones
Sauf qu’on donne du sens, dans certain cas, à la notion de
simultanéité
B1
A1
a
A1 B1
< 47 / 61 >
b
a
b
A1 B2
A2 B1
A2
B2
Parallèle asynchrone ...
Plus synchronisation
< 46 / 61 >
Un exemple de tous les jours :
un processus tableur, un processus éditeur de texte,
les échanges de données se font via le
« presse-papiers »du système Windows.
Plus généralement :
l’OS propose des mécanismes de mémoires protégées, de
files d’attentes (pipes) etc.
ça supprime les problèmes d’intégrité, mais attention aux
problèmes de blocage, de famine !
< 44 / 61 >
La programmation asynchrone, concrètement
int h = 0 ;
int m = 0 ;
mutex key ;
main(){
run(thread1) ;
run(thread2) ;
}
a || b
A2 B2
< 49 / 61 >
Le produit synchronisé (suite)
Modélisation du rendez-vous
on a des canaux de communication, (ex. X )
un canal particulier appartient à un couple (émetteur,
récepteur) déterminé
l’émetteur utilise l’action X (v )! pour envoyer la valeur v
le récepteur utilise l’action X (a)? pour récupérer une valeur
et l’affecter à la variable a
les deux actions sont blocantes !
la seule composition possible est : X (v )! || X (a)? , qui
résulte simplement en a = v
En général, seuls certains a || b sont possibles
Exemple classique où c’est utile : modéliser le rendez-vous :
le rendez-vous est un mécanisme de haut niveau fourni par
les OS pour pour programmer la communication synchrone
analogie avec une communication par téléphone (par
opposition à une communication par courrier)
< 50 / 61 >
Ordonnanceur
< 51 / 61 >
Le produit synchrone
Un exemple très simple, avec des rendez-vous « purs »
toutes les tâches avancent exactement au même rythme
seule la simultanéité a du sens
c’est le modèle du « parallélisme physique », dans le
matériel (i.e. hardware, circuits)
mais aussi du parallélisme logique, dans le domaine de la
« programmation synchrone »(session 6).
les communications sont instantanées (diffusion synchrone)
g1 ?
r1 !
g2 ?
r2 !
r2 ?
s1
g1 !
r2
g1
s1
s2
r1 ?
g2 !
s2
r1
g2
Le parallélisme asynchrone/synchronisé sera étudié en détail
dans la session 7.
< 52 / 61 >
Exemple d’un circuit
a
z1
labels « entrées/sorties »
notation a pour « a est vraie », ā pour « a est fausse »
Reg
·
r1
x
⊕
z2
produit normal : e1 /s1 ||e2 /s2 = e1 e2 /s1 s2
Reg
mais e1 x̄/xs2 impossible, tout comme e1 x/x̄s2 !
r2
·
C1
b
0
0
a/x̄
équations temporelles (temps = N) :
x(t) = a(t) · z1 (t)
b(t) = x(t) · z2 (t)
z1 (t) = r1 (t) ⊕ a(t) z2 (t) = r2 (t) ⊕ x(t)
r1 (0) = 0
r2 (0) = 0
r1 (t + 1) = z1 (t)
r2 (t + 1) = z2 (t)
a/x
1
ā/x̄
< 55 / 61 >
āx̄/x̄ b̄
x̄/b̄
ā/x̄
C2
< 54 / 61 >
Modèles et produit
deux compteurs modulo 2 connectés :
⊕
ax/xb
āx̄/x̄ b̄
x/b
1
x̄/b̄
00
ax̄/x̄ b̄
x/b̄
11
ax̄/x̄ b̄
10
01
āx̄/x̄ b̄
ax/x b̄
āx̄/x̄ b̄
< 56 / 61 >
Diffusion et boucles de causalité
Solutions aux boucles de causalité
accepter tout ce qui correct pour un “vrai” circuit (causalité
dite constructive)
interdire complètement les boucles combinatoires
problème inhérent à la diffusion synchrone
que faire quand x(t) = f (x(t)) ?
problème des boucles combinatoire en circuits :
certaines sont clairement des erreurs : x = ¬x
d’autres sont acceptables : x = c · y + c̄ · a y = c · b + c̄ · x
< 57 / 61 >
Attention :
on peut avoir une interdépendance entre x et y , à condition
d’avoir un retard :
x(t) = f (y(t)) y(t) = g(x(t − 1)) est toujours correct
analogie avec les courts-circuits : on met des “résistances”
(retards) pour les couper
Conclusion
< 59 / 61 >
Conclusion
Modéliser pour quoi faire ?
programmer juste, session 6 sur la programmation
synchrone
concevoir juste, session 7 sur les spécifications
asynchrones
vérifier formellement, après coup, session 9
< 58 / 61 >
Approche formelle = construction de modèles (mathématiques)
fidèles, permettant de raisonner sur les systèmes réactifs :
modèles des programmes séquentiels, mono-tâche =
systèmes de transitions étiquetés (automates)
modélisation du parallélisme = produit(s) d’automates
communicants
Attention :
plusieurs notions de parallélisme/communication =
plusieurs types de produits
Conclusion
Conclusion
Partie IV
< 61 / 61 >
< 60 / 61 >

Session 5 Modèles des systèmes réactifs et parallèles

Transcription

Documents pareils

PDF version - Le projet applique au territoire

Anglais professionnel

Conférence - Parcours Emploi Bassin Grenoblois

Docteur en informatique Ingénieur Télécom ParisTech

Voir mon CV au format PDF.

www.cnam.fr 1 UE 5AE01 Fondements de l`efficacit

Comment peut-on recevoir le catalogue des

Cédric Richardeau, ingénieur avant