Chapitre 5 ContextAA – Considérations architecturales
5.7 Temps
Le temps dans ContextAA est une préoccupation multifacettes. Composant important des systèmes contextualisés en général, il intervient dans ContextAA à plusieurs niveaux, que ce soit pour le suivi de l’exécution d’un Hôte, pour la discrétisation du temps pour un Agent, ou pour l’ordonnancement des événements dans l’espace ouvert.
Dans ContextAA, une caractéristique du temps est qu’il est contextifié, décrit par du Contexte, et donc assujetti aux mêmes contraintes que l’ensemble des Contextes. En particulier, les considérations soulevées dans §5.6.5 s’appliquent pleinement au temps : aucune présomption n’est faite dans ContextAA quant à un temps global en tant qu’état partagé envers lequel tous les Agents se seraient mis d’accord. En ceci, ContextAA prend acte des constats faits par Sheehy [102] plutôt que de suivre la proposition mise de l’avant par Weiss et al. [65] à l’effet que l’IdO dépendrait d’horloges synchronisées à très haute précision.
La philosophie qui sous-tend ContextAA est à l’effet qu’il est contre-productif de chercher un état global dans un système réparti ouvert. Une plus forte synchronisation entre les horloges des Agents de ℎ et de 𝑁ℎ y est vue comme un bonus, pas comme une nécessité, du fait que tout Agent doit être
pensé au préalable pour tenir compte du fait que les horloges des Agents sur divers Hôtes peuvent diverger.
5.7.1 Moments d’un Agent
Dans la figure 15, la mention « … » apparaissant entre les opérations publier et consommer d’un Agent 𝑎 représente le « moment » entre l’action de publier et l’action de consommer pour 𝑎. Pendant ce temps, au sens de 𝑎, le temps passe et des événements se produisent, et les conséquences de ces événements ne seront visibles pour 𝑎 que lors de sa propre prochaine étape consommer. L’exécution itérative d’un Agent 𝑎 entraîne une discrétisation du temps pour 𝑎 : le temps passe pour 𝑎: ℎ de manière discrète, une itération à la fois dans le cycle d’opération de ℎ. Ce que décrit « … » dans la figure 15 est l’ensemble des événements externes aux actions de 𝑎 qui se produisent entre l’étape publier et l’étape consommer de l’opération de 𝑎, ce qui inclut les actions de ∀𝑎′ ∈
160
Nous nommons « moment de 𝑎 » pour 𝑎 ∈ Α, 𝑎 ∈ ℎ une itération de 𝑎 dans le cycle d’exécution de ℎ. Les moments de 𝑎 sont dénombrables et peuvent être annotés de manière telle qu’étant donné deux moments 𝑡𝑖, 𝑡𝑗; 𝑖, 𝑗 ∈ ℤ, nous avons 𝑡𝑖 < 𝑡𝑗 ⇔ 𝑖 < 𝑗 pour représenter 𝑡𝑖 précède 𝑡𝑗.
Deux moments 𝑡𝑖, 𝑡𝑗 sont dits consécutifs si ∄𝑡𝑘(𝑡𝑖 < 𝑡𝑘 < 𝑡𝑗); 𝑖, 𝑗, 𝑘 ∈ ℤ, ce qui équivaut en
pratique au cas où 𝑗 = 𝑖 + 1. Par cette définition, l’annotation des moments s’incrémente de manière monotone avec chaque moment d’un même Agent, ce qui permet de construire un ordonnancement des moments [62] pour un Agent donné sur un Hôte donné.
Entre deux moments consécutifs de 𝑎, 𝑆𝑎 est susceptible de changer de plusieurs manières, que ce soit par l’ajout de nouveaux Contextes (réponses à des requêtes soumises antérieurement, par exemple) ou par la suppression de Contextes périmés en accord avec les règles décrites dans 𝑂𝑎. Il existe une dichotomie entre le temps qu’on pourrait qualifier de « physique », celui qui semble progresser de manière continue sans égard aux actions d’un Agent donné, et le temps au sens d’un Agent, qui progresse par sauts discrets tels que le « monde » perçu par un Agent (l’état de 𝑆𝑎 ou
de 𝑆ℎ, selon l’Agent).
Dans ContextAA, pendant qu’un Agent opère, son « monde » ne change pas si lui-même ne le change pas, puisque le gestionnaire d’Agents d’un Hôte opère sur chaque Agent en séquence et puisque les actions asynchrones ou parallèles au cycle normal d’opération d’un Hôte sont réalisées par des objets autonomes, et puisque ces actions ne prennent effet que lorsque les Agents standards correspondants en consomment les fruits par des canaux de Contexte pour les intégrer à 𝑆ℎ. Aucun
événement asynchrone ne perturbe 𝑆𝑎 pendant l’action de 𝑎.
Si cela s’avère nécessaire, il est possible de construire une histoire de 𝑎 [17] à partir d’instantanés successifs de 𝑆𝑎, mais il est probable que cette histoire ne coïncide pas avec celle de ∀𝑎′ ∈
ℎ(𝑎′≠ 𝑎) en raison des différences entre 𝑂
𝑎 et 𝑂𝑎′. En effet, ce qui constitue du Contexte
dépendant de l’Agent, cette réalité distingue notre approche, qui utilise un cadre ontique par Agent et où chaque Agent n’observe qu’une partie des Contextes possibles, d’une approche avec Ontologie partagée où il est raisonnable de présumer que deux Agents auraient eu la même perspective sur le Contexte disponible.
5.7.2 Ordonnancement chronologique global
Le problème de l’ordonnancement des événements dans un système réparti a été adressé par plusieurs, dont Lamport [62] avec la relation Happens-Before et Chandy et Lamport [17] avec la constitution d’instantanés valides des états systémiques. Ces résultats sont toutefois soumis à des contraintes sévères, incluant celles d’un système fermé et de moyens de communication fiables entre les processus. La plupart des langages de programmation contemporains, par exemple C++ [51] décrivent des relations telles que Happens-Before, Sequenced-Before, Inter-Thread Happens-
Before, etc. mais dans le contexte d’un seul et même programme lorsque celui-ci s’exécute sur une
machine multi-cœurs.
ContextAA est conçu pour l’espace intelligent ouvert, dans lequel il n’est pas garanti que ces contraintes soient rencontrées. Pour cette raison, l’optique préconisée y est différente : les outils mis à la disposition des Agents favorisent le développement de perspectives subjectives sur le Contexte, et il n’est en général pas requis qu’il existe un ordonnancement global sur les événements.
161
Favoriser une perspective subjective sur le Contexte va de pair avec l’approche de ContextAA qui met de l’avant le Contexte-selon : les besoins, les règles de raisonnement, les traitements applicables au Contexte font tous, dans ContextAA, partie du cadre ontique d’un Agent, ou selon l’Agent. Ceci mène à une vision minimaliste du Contexte, ne visant à couvrir que les besoins des Agents véritablement déployés sur un Hôte donné. Conséquemment, un Agent ne requiert habituellement un ordonnancement global de certains événements que lorsque cet ordonnancement a des conséquences sur sa mission, ou impacte son cadre ontique.
5.7.3 Ordonnancement chronologique local
À l’intérieur d’un même Hôte ℎ, chaque Agent 𝑎 ∈ ℎ exécute tour à tour son cycle normal d’opération, ce qui induit une progression monotone et discrète des opérations pour 𝑎. Un Agent standard sur chaque Hôte est responsable de tenir à jour un compteur d’itérations du gestionnaire d’Agents de cet Hôte. Il est donc possible pour un Agent d’établir une chronologie des événements pour lui.
Au sens de l’ordonnancement des opérations entre Agents sur un même Hôte ℎ, les actions d’un Agent du domaine apparaissent simultanées au sens de Lamport [62], c’est-à-dire qu’il n’est pas possible pour un Agent du domaine d’observer un ordonnancement entre ses actions et celles des autres Agents du domaine du même Hôte. Ainsi, pour un Agent du domaine 𝑎 ∈ ℎ, les opérations s’expriment au présent, en termes du contenu de 𝑆𝑎.
Les actions des Agents standards, pour leur part, suivent une séquence déterminée par le gestionnaire d’Agents de leur Hôte. Du point de vue des Agents du domaine, ces actions semblent faites de manière asynchrone, leurs effets ne pouvant être constatés qu’une fois qu’elles ont été complétées. Ainsi, au sens mis de l’avant par Herlihy et Wing [43], ces opérations sont linéarisables.
5.7.4 Ordonnancement chronologique entre Hôtes
Bien que la détermination d’un ordonnancement global d’événements entre Hôtes distincts dans l’espace ouvert semble hors de portée de manière générale, il est possible de tracer un ordonnancement entre Hôtes pour certains événements clés. Soit ℎ, ℎ′: 𝐻 :
lors de ℎ→ ℎ𝑐 ′, l’envoi de 𝑐 par ℎ précède globalement la réception de 𝑐 par ℎ′;
en particulier, lors de ℎ→ ℎ𝑎 ′, le début de la migration de 𝑎 à partir de ℎ précède son arrivée sur
ℎ′;
toutefois, placé face à 𝑐, 𝑐′ ∈ 𝐶 tels que 𝑐 est produit par 𝑎 ∈ ℎ à un moment 𝑡 selon 𝑎 et 𝑐′ est
produit par 𝑎′∈ ℎ′ à un moment 𝑡′ selon 𝑎′, il n’est pas nécessairement possible de déterminer
une chronologie entre 𝑡 et 𝑡′, donc d’ordonnancer 𝑐 et 𝑐′ sur la base de leur moment de
production.
En pratique, pour un Agent 𝑎′′ observateur de 𝑐 et 𝑐′, cet indéterminisme peut ne pas être
problématique :
si 𝑎′′ suppose que les horloges sur lesquelles sont basés 𝑡 et 𝑡′ sont suffisamment près d’être
synchronisées pour être considérées équivalentes en pratique, alors 𝑐 précèdera 𝑐′ au sens de 𝑎′′
162
si 𝑎′′ est en mesure d’estimer la différence entre les horloges sur lesquelles sont basés 𝑡 et 𝑡′,
alors il est possible pour 𝑎′′ d’appliquer une correction sur 𝑡 et 𝑡′ pour en arriver à établir un
ordonnancement entre eux, ce qui peut se faire à la manière de ce que font des protocoles tels que NTP [68]. Dans ce cas, un Agent standard sur ℎ peut tenir à jour les écarts apparents d’horloges ∀ℎ′∈ 𝑁
ℎ de manière à ce que ∀𝑎 ∈ ℎ ait accès localement au fruit de ce calcul des
écarts.
La qualité de ces estimations peut être réduite si les horloges sont irrégulières, non-monotones, ou encore si les Contextes consultés n’ont pas été produits récemment, accroissant les risques que les estimés des différences entre les temps de production soient inadéquats. Conséquemment, il est préférable pour 𝑎′′ de ne pas faire reposer son estimé de qualité relative entre deux Contextes sur
la seule base de leur « fraîcheur », donc du caractère récent ou non de leur moment de production.