Syst` eme 1 maˆıtre-2 esclaves

Nous avons consid´er´e jusqu’`a pr´esent que notre syst`eme ne comportait qu’un seul maˆıtre et un seul esclave afin de d´etailler l’essence mˆeme des raffinements possibles pour une transaction. Cependant, cette configuration limite les comportements permis ´evitant certains probl`emes dus `a la concurrence. Nous consid´erons maintenant un syst`eme poss´edant un maˆıtre et deux esclaves (figure 4.9). N´eanmoins, mˆeme si la figure s’apparente `a une diffusion de la part du maˆıtre, nous consid`ererons qu’un seul esclave peut ˆetre sollicit´e `a la fois. Il nous faut alors distinguer les transactions telles qu’elles sont vues par les diff´erents acteurs du syst`eme.

Maître 1

Esclave 1 Esclave 2

Figure 4.9 – Un maˆıtre-deux esclaves (d´emux)

Les contraintes exprim´ees par les ´equations 4.2 restent n´ecessaires mais ne repr´esentent que le flot global de transactions. Il faut introduire des horloges auxiliaires aux interfaces de nos diff´erents composants. Pour le cas du seul maˆıtre, ces horloges ne sont qu’une simple copie des horloges globales. C’est pourquoi nous les assimilerons, dans ce cas bien particulier, aux horloges globales du m´edia de transport. Pour les esclaves, les horloges de leurs interfaces r´esultent du d´emultiplexage des horloges globales. A priori, le syst`eme semble pouvoir s’exprimer par les contraintes d’horloges d´etaill´ees ci-apr`es.

Slave1 begin req ' Slave1 end req

Slave1 end req 4 Slave1 begin resp

Slave1 begin resp ' Slave1 end resp

Slave2 begin req ' Slave2 end req

Slave2 end req 4 Slave2 begin resp

Slave2 begin resp ' Slave2 end resp (4.4)

Les six contraintes d´ecrites par les ´equations 4.4 repr´esentent le flux vu des esclaves num´ero un et deux ind´ependamment du flux global.

begin req = Slave1 begin req + Slave2 begin req

end req = Slave1 end req + Slave2 end req

begin resp = Slave1 begin resp + Slave2 begin resp

end resp = Slave1 end resp + Slave2 end resp (4.5)

Les quatre contraintes d´ecrites par les ´equations 4.5 lient le flux global aux flux des esclaves.

Slave1 begin req # Slave2 begin req

Slave1 begin resp # Slave2 begin resp (4.6)

Les contraintes des ´equations 4.6 assurent l’acc`es exclusif aux deux esclaves.

Nous consid´erons, ici encore, une relation de pr´ec´edence comme comportement ´emergent mais faisons l’hypoth`ese que l’ordre entre les occurrences d’´ev´enements end req et begin resp est conserv´e. Ainsi, nous ´evitons de consid´erer les comportements de la trace d´ecrite `a la fi- gure 4.10, dans laquelle une inversion d’ordre dans la r´eception des r´eponses provenant des esclaves (Slave1 begin resp et Slave2 begin resp) peut apparaˆıtre bien que l’ordre de chaque esclave soit respect´e ind´ependamment. On remarque dans cette figure que la deuxi`eme tran- saction d´ebut´ee par le maˆıtre (deuxi`eme occurence de begin req) est bien prise en compte par

l’esclave 1 (leur deuxi`eme occurrence de begin req et end req sont synchrones). Cependant, le d´ebut de r´eponse que le maˆıtre obtient (deuxi`eme occurence de begin resp) ne co¨ıncide pas avec le d´ebut de r´eponse initi´e par l’esclave 1 mais co¨ıncide avec le d´ebut de la troisi`eme transaction qu’il initie `a destination de l’esclave 2.

end_req begin_resp end_resp begin_req Master Slave1 Slave2 end_req begin_resp end_resp begin_req end_req begin_resp end_resp begin_req 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 3 3 3 3 1 1 1 1

Figure 4.10 – Inversion d’ordre de terminaison de transactions

Quoi qu’il en soit, nous basant sur les sp´ecifications du protocole amba ambaweb, nous nous sommes aper¸cus que ce probl`eme ´etait r´esolu par le for¸cage d’un comportement bien particulier qui contrˆole l’ordre de retour. A l’analyse de la sp´ecification de ce protocole, il apparaˆıt d’une part qu’un maˆıtre ne peut d´ebuter une nouvelle transaction que lorsque la pr´ec´edente a ´et´e prise en compte. D’autre part la r´eponse d’un esclave n’est valide qu’`a partir d’un certain moment qu’il notifie au maˆıtre. Ces deux ph´enom`enes ont un point en commun : ils sont notifi´es par le mˆeme ´ev´enement (`a savoir le signal hready). Lorsque cet ´ev´enement se produit, cela signifie `a la fois que la requˆete pr´ec´edente a bien ´et´e prise en compte (permettant de d´ebuter une nouvelle) et que la r´eponse est disponible sur le m´edia de communication (garantissant que la r´eponse est

bien celle de la requˆete pr´ec´edente). D’un point de vue relation, cela revient `a consid´erer une forme plus rudimentaire de la transaction (d´ecrite par les ´equations 4.7). Nous consid´ererons donc par la suite une mod´elisation de la transaction compos´ee de trois horloges contraintes par les relations d´ecrites par les ´equations 4.7

Maître Esclave Requête Réponse @begin @hready @end

Figure 4.11 – Transaction simplifi´ee

begin ' hready

hready ' end

(4.7)

o`u begin (resp. end) est l’´equivalent de l’horloge begin req (resp. end resp) initiale et hready l’horloge for¸cant la synchronisation entre end req et begin resp (et interdisant par la mˆeme occa- sion les inversions d’ordre de retour des r´eponses). Ainsi, une transaction s’en retrouve simplifi´ee de la mani`ere d´ecrite dans la figure 4.11. Comparativement `a la version “AT”, elle ne contient plus que deux phases. Pour un syst`eme ´equivalent `a la figure 4.9, une trace d’ex´ecution est don- n´ee dans figure 4.12. L’ordre de passage des messages est forc´e (`a l’inverse du comportement de la figure 4.10). Le probl`eme d’inversion ne peut plus apparaitre, les relations de pr´ec´edences h´erit´ees de la relation d’alternance l’interdisant.

Une g´en´eralisation des contraintes `a un ensemble fini d’esclaves est donn´ee dans l’annexe C.