“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 186 — #196
i
i
i
i
i
i
i
i
186
4
• La programmation concurrente dataflow
les bonnes propriétés du modèle déclaratif. Nous appelons le modèle résultant
modèle concurrent dataflow ou modèle déclaratif concurrent.
– La deuxième étape étend le modèle avec l’exécution paresseuse. Nous ajoutons
la synchronisation par besoin et l’instruction WaitNeeded. L’appel {WaitNeeded X} attend jusqu’à ce qu’une opération ait besoin de X. Par exemple, si
on fait une addition X+Y ou une correspondance de formes case X of ...
end, le {WaitNeeded X} continuera son exécution. Avec WaitNeeded on
peut définir des fonctions paresseuses, qui seront évaluées seulement si on a
besoin de leur résultat. Oz a une abstraction linguistique, fun lazy, pour les
fonctions paresseuses. Nous appelons le modèle résultant modèle concurrent
paresseux. Ce modèle garde aussi les bonnes propriétés du modèle déclaratif.
C’est le modèle déclaratif le plus expressif que nous connaissons.
Nous présentons uniquement le modèle concurrent dataflow. Le modèle concurrent
paresseux dépasse la portée de cet ouvrage.
Dans le modèle concurrent dataflow, s’il y a une erreur pendant l’exécution il est
possible que l’exécution sorte du modèle parce qu’elle n’est plus déclarative. Cela
peut être traité en ajoutant des exceptions au modèle comme nous avons ajouté les
exceptions au modèle déclaratif. Ainsi, on peut détecter et éventuellement réparer
l’erreur pour que l’exécution reste déclarative si on le souhaite.
4.1.1 Les concepts de base
Nous étendons le modèle déclaratif avec la possibilité d’avoir plusieurs piles sémantiques qui s’exécutent « en même temps » avec une mémoire partagée. Cela donne le
modèle illustré dans la figure 4.1 avec le langage noyau du tableau 4.1. Le langage
noyau étend la figure 2.1 avec la nouvelle instruction thread.
Memoire à affectation unique
...
ST1
ST2
STn
(‘‘fils’’)
Plusieurs piles sémantiques
U
X
W=atom
Y=42
Z=person(age: Y)
Figure 4.1 Le modèle concurrent dataflow.