5.3.2 Algorithmes barrière . . . 130
Conclusion . . . 134
C
e chapitre peut être considéré comme une validation du travail réa-lisé dans le chapitre 3. Après l’obtention de la spécification LOTOS modélisant notre système et avant d’entamer la phase d’évaluation des performances, il est indispensable de vérifier que les aspects logiciels et matériels ont été correctement modélisés.La vérification est un processus de démonstration de la correction fonc-tionnelle d’un système. Il existe plusieurs méthodes de vérification, les principales étant le test, la preuve de théorèmes et le model-checking (littérale-ment : "vérification de modèle").
Le test permet de découvrir de nombreuses erreurs, mais il ne peut pas être exhaustif et n’apporte donc que des réponses partielles. Dans la preuve de théorème, le système est considéré comme un ensemble d’axiomes qui servent à prouver des propriétés, c’est une méthode qui permet en principe de répondre à toutes les questions de vérification qui se posent en pratique, mais sa mise en œuvre est souvent lourde et compli-quée. Le model-checking [11] est en quelque sorte intermédiaire : il s’agit d’une méthode exhaustive et en grande partie automatique.
Pour vérifier automatiquement un système par la méthode du model-checking, il est nécessaire de :
• Construire une modélisation formelle du système au moyen d’un
langage de spécification de système de haut niveau ayant une séman-tique opérationnelle bien définie, comme le langage LOTOS. La des-cription du système est ensuite traduite automatiquement vers un modèle sous-jacent, qui est souvent un STE (Système de Transitions
Etiquetées).
• Spécifier les propriétés à vérifier au moyen d’un langage de
spécifica-tion de propriétés, comme les logiques temporelles, qui sont des for-malismes bien adaptés pour spécifier les propriétés de bon fonction-nement du système.
• Enfin, il faut disposer d’un algorithme capable de déterminer si le système satisfait ou non les propriétés spécifiées. Cet algorithme est incarné dans un model-checker (un outil pour le model-checking), per-mettant de fournir un diagnostic d’erreur complétant utilement la vé-rification d’une propriété qui n’est pas satisfaite. Nous utilisons le model-checker EVALUATOR [66] de la boîte à outils CADP.
La logique temporelle a été introduite pour la première fois par Pnueli en 1977 [79] pour l’étude du comportement des programmes parallèles. C’est une forme de logique dont les énoncés et les raisonnements font intervenir la notion d’ordonnancement dans le temps. L’idée de son utili-sation pour qualifier le comportement des programmes est assez naturelle, elle vient de sa manipulation des propositions dont la vérité évolue dans le temps : l’état d’un système change au cours de l’exécution du programme et, en conséquence, les propriétés de l’état changent également.
Remarque 4.1 La notion du temps dans la logique temporelle, n’est pas explicitement utilisée comme une durée absolue. Par exemple, dans la propriété :"chaque fois que j’ob-serve Q, j’ai observé P avant", il peut a priori se passer une seconde ou une
journée entre l’observation de P et l’observation de Q. Les logiques manipulant
explicitement le temps sont dites deslogiques temporisées [39].
Les descriptions de propriétés en logiques temporelles présentent deux qualités importantes [63] : elles sont abstraites pour leur indépendance des détails de l’implémentation de l’application et elles sont modulaires, parce que la modification, l’ajout ou la suppression d’une propriété n’impacte pas la validité des autres propriétés.
Le choix d’une logique temporelle parmi la multitude des logiques temporelles existantes dans la littérature (une synthèse sur les plus re-présentatives peut être trouvée dans [65]), doit prendre en considération plusieurs aspects :
• L’expressivité: la capacité de la logique à exprimer les classes de pro-priétés intéressantes, telles que la sûreté, la vivacité, ou l’équité.
• La complexité d’évaluation: la complexité des algorithmes permettant de vérifier qu’un modèle satisfait une propriété.
• La facilité d’utilisation: la capacité d’exprimer les propriétés de ma-nière concise et naturelle.
L’optimisation de l’un ou l’autre de ces aspects ne pouvant généra-lement se faire qu’au détriment des autres, le choix doit passer par un compromis judicieux, par exemple si l’efficacité d’évaluation est l’aspect le plus important, alors l’expressivité de la logique devra être limitée.
Nous présentons dans ce chapitre le µ-calcul régulier : la logique tem-porelle du model-checker EVALUATOR. Nous mettons l’accent par la suite sur la description et la vérification des propriétés de bon fonctionne-ment de notre système.
Le µ-calcul régulier [66] est la logique temporelle utilisée dans EVALUA-TOR, elle fait partie des logiques temporelles avec opérateurs de point fixe, connues pour leur expressivité et utilisées pour la description de pro-priétés arborescentes sur les STEs.
Le µ-calcul régulier remplace les formules sur les actions de µ-calcul modal [56] avec les formules régulières de PDL [18]. Bien que cette exten-sion n’augmente pas l’expressivité de la logique par rapport au µ-calcul modal standard, la description des propriétés en µ-calcul régulier est ren-due plus simple et conviviale grâce à l’utilisation des opérateurs réguliers à la place des opérateurs de point fixe.
Nous présentons dans ce qui suit la syntaxe et la sémantique du µ-calcul régulier, pour cela nous considérons un STE M donné par la défini-tion 4.1 décrivant tous les comportements possibles du système.
Définition 4.1 Un système de transitions étiquetées est un quadruplet M= (S, A, T, s0), où : • S est un ensemble fini d’états
• A est un ensemble fini d’actions
• T ⊆ S×A×S est un ensemble de transitions. Une transition (s1, a, s2) ∈ T, notée également s1 →a s2, signifie que le système peut passer de l’état s1à l’état s2en exécutant l’action a.
• s0∈ S est l’état initial.
Remarque 4.2 Un système de transitions étiquetées peut être vu comme un graphe orienté, muni d’un état initial et dont les arcs sont étiquetés par des actions. Par conséquent, l’ensemble du vocabulaire défini pour les graphes reste valide, en particulier les notions usuelles de chemin et circuits.
4.1.1 La syntaxe
Le µ-calcul régulier contient trois types d’entités : les formules sur actions (notées α), les formules régulières (notées β) et les formules sur états (no-tées ϕ).
• Les formules sur actions sont construites au-dessus du vocabulaire des actions a ∈ Aau moyen des opérateurs booléens standard.
α::=a | ¬α1 |α1∧α2
Les opérateurs booléens dérivés sont définis comme suit :
F =a∧ ¬a, T= ¬F, α1∨α2 = ¬(¬α1∧ ¬α2)
• Les formules régulières sont construites à partir des formules sur
ac-tions et des opérateurs des expressions régulières standard, comme la concaténation (.), le choix (|) et la fermeture transitive et réflexive (*). L’opérateur de séquence vide (ε) et l’opérateur de répétition une ou plu-sieurs fois (β+) sont définis respectivement par : ε= F∗ et β+= β.β∗.
• Les formules sur états sont construites sur des variables proposition-nelles Y ∈ Υ, au moyen des opérateurs booléens standard, des modali-tés de possibilité (hβiϕ) et de nécessité ([β]ϕ) et des opérateurs minimal (µY.ϕ) et maximal (νY.ϕ) de point fixe.
ϕ::=F| T |ϕ1∨ϕ2 |ϕ1∧ϕ2 | hβiϕ| [β]ϕ|Y|µY.ϕ|νY.ϕ
4.1.2 La sémantique
• La sémantique d’une formule α sur le STE M est définie par l’interpré-tation kαk ⊆ A, qui dénote le sous-ensemble d’actions de A satisfaisant
α. Les opérateurs booléens ont la sémantique habituelle définie en termes d’opérations ensemblistes.
kak = {a} k¬αk = A\kαk kα1∧α2k = kα1k ∩ kα2k
• La sémantique d’une formule β est définie par l’interprétation kβk ⊂ S×S, qui dénote les couples d’états qui sont aux extrémités des séquences de transitions satisfaisant β. Les formules régulières atomiques α dénotent les séquences comportant une seule transition étiquetée par une action satisfaisant α. Les formules β1.β2, β1|β2, et β∗ dénotent respectivement la concaténation, le choix et la répétition (zéro ou plusieurs fois) de sé-quences de transitions satisfaisant β1, β2 et β (◦, ∪ et * dénotent respecti-vement la composition, l’union et la fermeture transitive et réflexive d’une relation).
kαk = {(s1, s2) ∈S×S| ∃a∈ kαk.s1 →a s2} kβ1.β2k = kβ1k ◦ kβ2k
kβ1|β2k = kβ1k ∪ kβ2k kβ∗k = kβk∗
• La sémantique d’une formule ϕ est définie par l’interprétationkϕkρ⊆ Squi dénote un sous ensemble d’états de S, avec ρ : Y →2Sun
environ-nement associant des sous-ensembles d’états à toutes les variables propo-sitionnelles libres dans ϕ ( ∅ dénote que : (ρ1∅ρ2)(Y) est égal à ρ2(Y) si ρ2 affecte Y et ρ1(Y) sinon). La modalitéhβiϕdénote les états ayant au moins une séquence de transitions successeur satisfaisant β et menant à un état satisfaisant ϕ La modalité[β]ϕdénote les états dont toutes les séquences de transitions successeurs satisfaisant β mènent à des états satisfaisant ϕ. Les deux opérateurs modaux sont duaux :[β]ϕ= ¬hβi¬ϕ, et monotones : si ϕ1 ⇒ ϕ2 alors hβiϕ1 ⇒ hβiϕ2 et[β]ϕ1 ⇒ [β]ϕ2. Les opérateurs µY.ϕ et
νY.ϕ dénotent respectivement la plus petite et la plus grande solution de l’équation Y= ϕdans un environnement ρ.
k k kTkρ = S kϕ1∧ϕ2kρ = kϕ1kρ∩ kϕ2kρ kϕ1∨ϕ2kρ = kϕ1kρ∪ kϕ2kρ khβiϕkρ = {s1∈S | ∃s2∈ S.(s1, s2) ∈ kβk ∧s2 ∈ kϕkρ} k[β]ϕkρ = {s1∈S | ∀s2∈ S.(s1, s2) ∈ kβk ⇒s2∈ kϕkρ} kYkρ = ρ(Y) kµY.ϕkρ = T{S′ ⊆S |Φρ(S′) ⊆S′} kνY.ϕkρ = S{S′ ⊆S |S′ ⊆Φρ(S′)} Avec: Φρ: 2S→2S, Φρ(S′) = kϕk(ρ Ø[S′/Y])}
4.2 Spécification des propriétés
La validation du modèle LOTOS de notre système se traduit par la vérifi-cation de la bonne modélisation des aspects matériels et logiciels :
• La vérification des aspects matériels concerne le protocole de cohé-rence de caches (les états des caches, le type de transfert) et la latence d’accès en fonction des niveaux des transfert dans la topologie consi-dérée.
• La vérification des aspects logiciels concerne la correction de l’exé-cution de l’algorithme MPI : la gestion des verrous, les contraintes d’accès aux variables (partagées et privées) et l’ordonnancement des accès aux variables.
Un rendez-vous sur la porte action modélise un accès en lecture, en écriture ou en lecture-écriture atomique à une variable de l’algorithme MPI :
ACTION ? P :ID_Processor(* Identificateur du processus demandeur*)
? adr :Address(* Nom de la variable *)
? op :ID_Action(* Type d’accès : Load, Store, ...*)
? val :Memory_Value(* La valeur lue ou écrite *)
? latency :Latency_Value ;(* La latence de l’accès *)
Les informations décrites sur les offres de la porte action s’avèrent suffisantes pour la réalisation d’un accès et l’évaluation de sa latence, en revanche nous n’avons aucune information sur les nouveaux états des caches et sur le transfert (type et niveau) pour s’assurer que l’accès res-pecte bien les règles du protocole de cohérence de caches et que la latence a été correctement évaluée dans la topologie considérée. Par conséquent, la spécification de ces informations en LOTOS est jugée indispensable pour la vérification de la correction de la modélisation des aspects matériels.
Nous présentons dans ce qui suit les nouveaux types algébriques en LOTOS que nous avons modélisés pour mener à bien la vérification des
aspects matériels. Il s’agit d’un type spécifiant les états d’une ligne de caches, un type spécifiant les différents types possibles d’un transfert et un type spécifiant les différents niveaux possibles d’un transfert.
•Les états des lignes de caches sont modélisés en LOTOS par le type Cache_Line, implémenté en C par adt_cache_line. Suivant le principe
de modélisation des caches que nous avons présenté dans la section 3.1, une ligne de cache dénote l’état d’une variable dans le cache de tous les processeurs du système.
type Cache_Line is Cache, Address
sorts Cache_Line (* ! implementedby adt_cache_line
printedby adt_print_cache_line external *) opns
State_Cache_Line (* ! implementedby adt_state_cache_line external *) : Cache, Address -> Cache_Line
endtype
L’opération State_Cache_Line prend en entrée les caches et l’indice d’une variable et retourne en sortie son état dans le cache de tous les processeurs du système. Par exemple, l’état de ligne de cache de la va-riable count de l’algorithme barrière centralized entre 3 processus, après initialisations de caches et avant tout accès est donné par : (P0, I)(P1, I)(P2, I).
Remarque 4.3 Pour des raisons de précision et de clarté, nous avons préféré la définition du nouveau type Cache_Line à l’exploitation du type Cache, pour les raisons sui-vantes :
1. La taille de la structure caches est fixe (dépendant du nombre de variables et de processus), par conséquent on ne peut pas définir une opération dans le type Cache qui retourne une ligne de caches dans un type Cache. 2. La fonction d’impression du type Cache (générée par le compilateur
CAE-SAR ou définie par l’utilisateur) permet l’affichage du contenu de toute la structure cache, en effet, c’est une fonction non-paramétrable.
•Le type du transfert est modélisé par le type Transfer_Type en LOTOS.
Il spécifie l’endroit où la donnée est chargée : Internal, Memory, Cache et
MemoryInv.
type Transfer_Type is Natural sorts Transfer_Type
opns
Internal (* ! constructor *), Cache (* ! constructor *), Memory (* ! constructor *),
MemoryInv (* ! constructor *) : -> Transfer_Type
TOS. Il spécifie les 4 niveaux des structures hiérarchiques des architectures FAME et MESCA : Internal, Intra_Node, Inter_Node et Inter_Module.
type Transfer_Level is Natural sorts Transfer_Level
opns
Internal (* ! constructor *), Intra_Node (* ! constructor *), Inter_Node (* ! constructor *),
Inter_Module (* ! constructor *) : -> Transfer_Level
endtype
• Les opérations d’évaluation des paramètres d’un accès : le type de
transfert, le niveau de transfert, l’identificateur du fournisseur de la don-née (cache ou mémoire), le niveau de consultation et/ou invalidation et la latence de l’accès, ont été regroupés dans un seul type Evaluation.
type Evaluation is Memory, Cache, ID_Action, ID_Processor, Address,
Transfer_Type, Transfer_Level, Latency_Value
sorts Evaluation (* ! implementedby adt_evaluation external *) opns
Evaluation_Latency
(* ! implementedby adt_evaluation_latency external *)
: Memory, Cache, ID_Action, Address, ID_Processor -> Latency_Value Evaluation_Transfer_Type
(* ! implementedby adt_evaluation_transfer_type external *)
: Memory, Cache, ID_Action, Address, ID_Processor -> Transfer_Type Evaluation_ID_Provider
(* ! implementedby adt_evaluation_id_provider external *)
: Memory, Cache, ID_Action, Address, ID_Processor -> ID_Processor Evaluation_Transfer_Level
(* ! implementedby adt_evaluation_transfer_level external *) : Memory, Cache, ID_Action, Address, ID_Processor -> Transfer_Level Evaluation_Inv_Level
(* ! implementedby adt_evaluation_inv_level external *)
: Memory, Cache, ID_Action, Address, ID_Processor -> Transfer_Level
endtype
Question ? Comment intégrer ces nouveaux types dans la spécification LOTOS ?
Nous avons analysé deux solutions possibles :
Solution 1: définition de nouvelles offres sur la porte action.
Solution 2 : définition d’une nouvelle porte verif dans le processus transfer dont le rendez-vous a lieu après une synchronisation sur la porte action.
La première solution révèle une certaine lourdeur dans sa mise en œuvre, en dépit de la taille de l’espace d’états préservé (à la différence
des transitions générées, dont les étiquettes augmentent en taille) : d’une part, il faut ajouter les offres sur tous les rendez-vous de la porte ac-tiondans tous les processus LOTOS participant aux synchronisations sur cette porte et, d’autre part, ces informations ne sont utiles que dans la phase de vérification. Nous avons dès lors opté pour la seconde solution et pour plus de généricité, nous avons défini un nouveau processus LO-TOS transfer_verif accomplissant les mêmes fonctionnalités du proces-sus transfer mais avec la précision de tous les paramètres d’accès sur la porte verif. Dans la spécification LOTOS nous avons le choix entre l’utilisation du processus transfer pour une étude des performances ou transfer_verif pour la vérification.
process TRANSFER_VERIF [ACTION, VERIF] (M :Memory, C :Cache) : noexit := ACTION ? P :ID_Processor ? adr :Address ? op :ID_Action
? val :Memory_Value ? latency :Latency_Value [
(((op == Load) and (val == Load_Memory(M, adr))) or ((op == Fetch_and_decrement) and
(val == Load_Memory(UpDate_Memory(M, adr, op, val), adr))) or (op == Store)
) and
(latency == Evaluation_Latency(M, C, op, adr, p)) ] ; VERIF ! p of ID_Processor (*1*) ! op of ID_Action (*2*) ! adr of Address (*3*) ! val of Memory_Value (*4*) ! State_Cache_Line(C,adr) of Cache_Line (*5*) ! State_Cache_Line(UpDate_Cache(C,op,adr,p),adr) of Cache_Line(*6*) ! Evaluation_Transfer_Type(M,C,op,adr,p) of Transfer_Type (*7*) ! Evaluation_ID_Provider(M,C,op,adr,p) of ID_Processor (*8*) ! Evaluation_Transfer_Level(M,C,op,adr,p) of Transfer_Level (*9*) ! Evaluation_Invalidation_Level(M,C,op,adr,p) of Transfer_Level (*10*) ! latency of Latency_Value ; (*11*)
TRANSFER_VERIF [ACTION, VERIF] (UpDate_Memory(M, adr, op, val), UpDate_Cache(C, op, adr, P))
endproc
Le processus transfer_verif dénote un comportement de fonctionna-lité noexit. Il est paramétré par deux portes de communication : action et verifet par variables, une de type Memory et une autre de type Cache. Le rendez-vous sur la porte action est identique à celui dans le processus transfer. Le rendez-vous sur la porte verif reprend les informations ob-tenues dans le rendez-vous sur action dans les offres 1, 2, 3, 4 et 11 et, à l’aide des fonctions d’évaluation des paramètres d’un accès, il spécifie les informations concernant : l’état de la ligne des caches de la variable adr avant (offre 5) et après (offre 6) l’accès, le type de transfert (offre 7), l’iden-tificateur du processeur fournisseur de la donnée (offre 8), le niveau de transfert (offre 9) et le niveau d’invalidation (offre 10).
EVALUATOR permet la définition et l’utilisation de macros pour spécifier des opérateurs temporels paramétrés par des formules sur actions et / ou sur états, ce qui offre la possibilité de construire des bibliothèques réutilisables.
Nous avons défini une bibliothèque "macros.mcl" contenant des défi-nitions de prédicats de base sur les transitions du STE. En effet, comme toutes les informations dont nous avons besoin pour la vérification sont fournies par les rendez-vous sur la porte verif, nous avons défini une macro de base nommée Action_Verif, paramétrée par les différentes offres décrites dans le rendez-vous sur verif.
Ci-dessous la définition de la macro Action_Verif pour un nombre de processus égal à 2.
macroAction_Verif( id_proc, action, adr, id_proc_adr, val, state_after_0, state_after_1, state_before_0, state_before_1, transfer_type, id_provider, transfer_level, inv_level, latency) =
’VERIF ! P’ # id_proc # ’ !’ # action # ’ !’ # adr #”# id_proc_adr # ’ !’ # val # ’ !(P0, ’ # state_after_0 # ’)(P1, ’ # state_after_1 # ’)’ ’ !(P0,’ # state_before_0 # ’)(P1,’ # state_before_1 # ’)’ ’ !’ # transfer_type # ’_TRANSFER’ ’ !’ # id_provider # ’ !’ # transfer_level # ’ !’ # inv_level # ’ !’ # latency # end_macro
Les chaînes de caractères entourées de guillemets simples (’) dénotent des expressions régulières, qui sont concaténées au moyen de l’opérateur ’#’ afin de former une expression régulière filtrant l’action complète effec-tuée sur la porte verif.
La bibliothèque macro.mcl est incluse en tête de chaque fichier consti-tuant des propriétés à vérifier. Les définition d’autres prédicats de base de cette bibliothèque sont disponibles dans l’annexe A.2.
Remarque 4.4 La définition de la macroAction_Verif varie en fonction du nombre de processus
participant à l’exécution de l’algorithme MPI en raison des offres indiquant l’état d’une ligne de cache.
4.2.2 Vérification des aspects matériels
Le but de la vérification des aspects matériels est de s’assurer de la cor-rection du fonctionnement du protocole de cohérence de caches et de la bonne évaluation des paramètres d’un accès (type de transfert, niveau de transfert, latence, . . .). Ceci permettra par la suite une analyse fiable des performances.
Nous avons vérifié les aspects matériels par des propriétés de sûreté (safety properties) [58], qui énoncent que "quelque chose de mauvais ne se
pro-duira jamais". Ces propriétés peuvent être exprimées de manière concise en
µ-calcul régulier au moyen de modalités "[F] R", où la formule régulière R représente les séquences d’actions indésirables qui doivent être absentes dans le modèle.
La propriété 4.1 spécifie les règles de changement des états des caches et les types de transfert engendrés dans le cas du protocole de cohérence de caches A (voir la définition de la macro CC_Load dans l’annexe A.2).
Propriété 4.1 S’il existe un accès dont les changements des états de caches et le type de transfert ne vérifient pas l’une des règles : RL1, RL3, RL4 ou RL6, alors il y a une erreur dans la modélisation du protocole de cohérence de caches A (voir la définition 1.4).
[
true *.
(
(*RL1 : LOAD(I,I)->(E,I)*)
not (CC_Load(’I’, ’I’, ’E’, ’I’, ’memory’, ’.*’) or CC_Load(’I’, ’I’, ’I’, ’E’, ’memory’, ’.*’)) and(*RL3 : LOAD(I,E)->(S,S) *)
not (CC_Load(’I’, ’E’, ’S’, ’S’,’memoryInv’,’.*’) or CC_Load(’E’, ’I’, ’S’,’S’,’memoryInv’, ’.*’)) and(*RL4 : LOAD(I,M)->(E,I) *)
not (CC_Load(’I’, ’M’, ’E’, ’I’, ’cache’, ’.*’) or CC_Load(’M’, ’I’, ’I’, ’E’, ’cache’, ’.*’)) and(*RL6 : LOAD(S,S)->(S,S) *)
not CC_Load(’S’, ’S’, ’S’, ’S’, ’internal’, ’.*’) and(*RL6 : LOAD(E,I)->(E,I) *)
not (CC_Load(’E’, ’I’, ’E’, ’I’, ’internal’, ’.*’) or CC_Load(’I’, ’E’, ’I’, ’E’, ’internal’,’.*’)) and(*RL6 : LOAD(M,I)->(M,I) *)
not (CC_Load(’M’, ’I’, ’M’, ’I’,’internal’, ’.*’) or CC_Load(’I’, ’M’, ’I’, ’M’, ’internal’, ’.*’))
) ] false
férents paramètres d’un accès pour deux processeurs dans une topology0.
Règle Demandeur Type Fournisseur Niveau Niveau Latence
transfert transfert Invalidation
RA1 P0 Internal P0 Internal Null c_int
RA2 P1 Internal P1 Internal Null c_int
RA3 P0 Cache P1 Intra_Node Null c_fsb
RA4 P1 Cache P0 Intra_Node Null c_fsb
RA5 P0/P1 Memory Memory Intra_Node Null m_fsb_1 RA6 P0 MemoryInv P1 Intra_Node Intra_Node m_fsb_1 RA7 P1 MemoryInv P0 Intra_Node Intra_Node m_fsb_1 Tab. 4.1 – Les règles de cohérence entre les paramètres d’un accès
A partir du tableau 4.1, nous définissons la propriété 4.2 pour la vérifica-tion de l’évaluavérifica-tion correcte des paramètres d’un accès (voir la définivérifica-tion de la macro Access dans A.2).
Propriété 4.2 S’il existe un accès dont les paramètres ne vérifient pas l’une des règles de cohé-rence : RA1, RA2, RA3, RA4, RA5, RA6 ou RA7, alors il y a une erreur dans les procédures d’évaluation. [ true *. ( (*RA1*) not Access(’0’,’internal’,’0’,’internal_level’,’nil_level’,’c_int’) and(*RA2*) not Access(’1’,’internal’,’1’,’internal_level’,’nil_level’,’c_int’) and(*RA3*) not Access(’0’,’cache’,’1’,’intra_node_level’,’nil_level’,’c_fsb’) and(*RA4*) not Access(’1’,’cache’,’0’,’intra_node_level’,’nil_level’,’c_fsb’) and(*RA5*) not Access(’.*’,’memory’,’.*’,’intra_node_level’,’nil_level’,’m_fsb_1’) and(*RA6*) not Access(’0’,’memoryInv’,’1’,’intra_node_level’,’intra_node_level’, ’’m_fsb_1’) and(*RA7*) not Access(’1’,’memoryInv’,’0’,’intra_node_level’,’intra_node_level’, ’’m_fsb_1’) ) ] false
4.2.3 Vérification des aspects logiciels
La vérification des aspects logiciels dépend fortement de l’algorithme MPI. Nous décrivons dans ce qui suit les propriétés que nous avons spéci-fiées pour vérifier le comportement de l’algorithme ping-pong et des al-gorithmes de barrières.
Algorithme ping-pong
Les propriétés de correction pour l’algorithme de ping-pong concernant principalement la gestion de verrous.
Il s’agit de vérifier l’exclusion mutuelle des accès aux variables parta-gées par les deux processus : la prise d’un verrou ne peut pas être effectuée par les deux processus en même temps et un processus ne peut pas libérer un verrou qu’il n’a pas pris auparavant. Nous avons exprimé cela par deux propriétés 4.3 et 4.4 pour la variable verrou available_lock (voir la définition