“doc” (Col. : Science Sup 17x24) — 2007/7/19 — 18:18 — page 213 — #223
i
i
i
i
i
i
i
i
4.4 Les principales limitations de la programmation déclarative
213
a) Une application client/serveur
Nous construisons maintenant une application client/serveur simple. Supposons qu’il
y ait deux clients indépendants. Être indépendants implique qu’ils sont concurrents.
Que se passe-t-il s’ils communiquent avec le même serveur ? Parce que s’ils sont
indépendants, le serveur peut recevoir des informations des deux clients dans n’importe
quel ordre. C’est un comportement non-déterministe observable.
Regardons de plus près pour voir si nous pouvons exprimer ce comportement dans
le modèle déclaratif concurrent. Le serveur a un flot d’entrée dont il lit ses commandes.
Commençons avec un client qui envoie des commandes au serveur. Cela fonctionne
parfaitement. Comment un deuxième client peut-il se connecter au serveur ? Il doit
obtenir une référence à un flot qu’il peut lier et qui est lu par le serveur. Le problème
est qu’un tel flot n’existe pas ! Il n’y a qu’un flot, entre le premier client et le serveur.
Le deuxième client ne peut pas lier ce flot, puisque cela causera des conflits avec les
liens du premier client.
Comment pouvons-nous résoudre ce problème ? Faisons une approche naïve pour
voir si nous pouvons trouver une solution. Une approche pourrait être de permettre le
serveur d’avoir deux flots d’entrée, comme ceci :
fun {Server InS1 InS2}
...
end
Mais comment le serveur lit-il ces flots ? Doit-il d’abord lire un élément de InS1 et
ensuite un élément de InS2 ? Doit-il lire simultanément un élément des deux flots ?
Aucune des deux solutions n’est correcte. En fait, il n’est pas possible d’écrire une
solution dans le modèle déclaratif concurrent. La seule chose que nous pouvons faire
est d’avoir deux serveurs indépendants, un par client. Mais ces serveurs ne peuvent
pas communiquer entre eux, sinon nous aurions de nouveau le même problème.
La figure 4.14 montre le problème : InS est le flot d’entrée du serveur et OutS1 et
OutS2 sont les deux flots de sortie des clients. Comment les messages qui apparaissent
sur les deux flots clients peuvent-ils être donnés au serveur ? La réponse simple est que
dans le modèle déclaratif concurrent, ils ne peuvent pas ! Dans ce modèle, un objet à
flots doit toujours savoir de quel flot il lit son prochain message.
Comment pouvons-nous résoudre ce problème ? Si les clients s’exécutent de façon
coordonnée et si le serveur sait toujours quel client va envoyer la commande suivante,
le programme sera déclaratif. Mais ce n’est pas réaliste. Pour écrire une vraie solution,
nous devons ajouter une opération non-déterministe au modèle, comme l’opération
WaitTwo mentionnée ci-dessus. Avec WaitTwo, le serveur peut attendre une commande de l’un ou l’autre client.
© Dunod – La photocopie non autorisée est un délit
i
i
i
i
i
i
i
i
4.4 Les principales limitations de la programmation déclarative
213
a) Une application client/serveur
Nous construisons maintenant une application client/serveur simple. Supposons qu’il
y ait deux clients indépendants. Être indépendants implique qu’ils sont concurrents.
Que se passe-t-il s’ils communiquent avec le même serveur ? Parce que s’ils sont
indépendants, le serveur peut recevoir des informations des deux clients dans n’importe
quel ordre. C’est un comportement non-déterministe observable.
Regardons de plus près pour voir si nous pouvons exprimer ce comportement dans
le modèle déclaratif concurrent. Le serveur a un flot d’entrée dont il lit ses commandes.
Commençons avec un client qui envoie des commandes au serveur. Cela fonctionne
parfaitement. Comment un deuxième client peut-il se connecter au serveur ? Il doit
obtenir une référence à un flot qu’il peut lier et qui est lu par le serveur. Le problème
est qu’un tel flot n’existe pas ! Il n’y a qu’un flot, entre le premier client et le serveur.
Le deuxième client ne peut pas lier ce flot, puisque cela causera des conflits avec les
liens du premier client.
Comment pouvons-nous résoudre ce problème ? Faisons une approche naïve pour
voir si nous pouvons trouver une solution. Une approche pourrait être de permettre le
serveur d’avoir deux flots d’entrée, comme ceci :
fun {Server InS1 InS2}
...
end
Mais comment le serveur lit-il ces flots ? Doit-il d’abord lire un élément de InS1 et
ensuite un élément de InS2 ? Doit-il lire simultanément un élément des deux flots ?
Aucune des deux solutions n’est correcte. En fait, il n’est pas possible d’écrire une
solution dans le modèle déclaratif concurrent. La seule chose que nous pouvons faire
est d’avoir deux serveurs indépendants, un par client. Mais ces serveurs ne peuvent
pas communiquer entre eux, sinon nous aurions de nouveau le même problème.
La figure 4.14 montre le problème : InS est le flot d’entrée du serveur et OutS1 et
OutS2 sont les deux flots de sortie des clients. Comment les messages qui apparaissent
sur les deux flots clients peuvent-ils être donnés au serveur ? La réponse simple est que
dans le modèle déclaratif concurrent, ils ne peuvent pas ! Dans ce modèle, un objet à
flots doit toujours savoir de quel flot il lit son prochain message.
Comment pouvons-nous résoudre ce problème ? Si les clients s’exécutent de façon
coordonnée et si le serveur sait toujours quel client va envoyer la commande suivante,
le programme sera déclaratif. Mais ce n’est pas réaliste. Pour écrire une vraie solution,
nous devons ajouter une opération non-déterministe au modèle, comme l’opération
WaitTwo mentionnée ci-dessus. Avec WaitTwo, le serveur peut attendre une commande de l’un ou l’autre client.
© Dunod – La photocopie non autorisée est un délit