Sensibilisation des processus

Comme on l’a évoqué au paragraphe 2.3, le choix d’un mode de sensibilisation des processus est un problème délicat. On a le choix de connecter les événements aux processus soit au moment de l’élaboration, soit lors de la simulation, soit de composer les deux mécanismes. Quelle relation y a-t-il entre tirage aléatoire, sensibilisation et modélisation des processus sachant que ceux-ci sont tous candidats à l’exécution à l’initialisation ?

Pour répondre à cette question, regardons ce qu’il se passe lorsque le tirage aléatoire des processus est activé. Considérons la spécification CSP décrite par l’équation P= →A B. Le système P exécute l’action A, puis l’action B, puis s’arrête. Nous proposons de modéliser le comportement de ce modèle par deux modules SystemC v2.0.1 hébergeant chacun un processus. Ces modules sont reliés par le canal de communication unidirectionnel point à point C, comme le montre la Figure 23.

La seule contrainte de modélisation sur l’action A consiste à émettre une requête. La seule contrainte de modélisation sur l’action B consiste à se synchroniser sur la requête provenant de A. Dans le cas général, on considère que le processus A effectue un précalcul avant l’émission de la requête et un postcalcul après l’émission de la requête. De même, on considère que le processus B fait un précalcul avant la synchronisation sur la requête et un postcalcul après la synchronisation sur la requête.

Figure 23 : Modèle SystemC v2.0.1 de la spécification P= →A B

2.5.2 Sensibilisation statique des processus

Considérons dans un premier temps une sensibilisation statique des processus. Pendant la phase d’élaboration, les liens entre les processus et les événements ainsi que les liens entre les événements et les processus sont créés. A l’initialisation, tous les processus, i.e. A et B sont candidats à l’exécution.

Puisque le tirage aléatoire des processus est activé, on peut obtenir plusieurs exécutions suivant que l’on commence la simulation par l’action A ou par l’action B.

Si on commence par A, on exécute A, qui déclenche B, puis B. Dans ce cas, il y a coïncidence entre le déclenchement de B du fait de la requête et le déclenchement de B du fait de l’initialisation. Cela conduit au comportement suivant :

1 pré_calcul_A() ; 2 notification(requête) ; 3 post_calcul_A() ; 4 pré_calcul_B() ; 5 synchronise(requête) ; 6 post_calcul_B() ;

Si on commence par B, on exécute B à l’initialisation, puis A qui déclenche B, puis B. Cela conduit au comportement suivant :

1 pré_calcul_B() ; 2 synchronise(requête) ; 3 pré_calcul_A() ; 4 notification(requête) ; 5 post_calcul_A() ; 6 pré_calcul_B() ; 7 synchronise(requête) ; 8 post_calcul_B() ;

La spécification n’est pas respectée. En effet, nous n’avons spécifié qu’un seul comportement et on en obtient deux. Le premier comportement correspond exactement à la spécification. Le second comportement ne répond pas à la spécification.

2.5.3 Sensibilisation dynamique des processus

Considérons dans un second temps la sensibilisation dynamique des processus. Pendant la phase d’élaboration, seuls les liens entre les processus et les événements sont créés. Les liens entre les événements et les processus ne sont créés que pendant la simulation sur les points de synchronisation des processus avec le noyau. A l’initialisation, tous les processus, i.e. A et B sont candidats à l’exécution.

Puisque le tirage aléatoire des processus est activé, on peut obtenir plusieurs exécutions suivant que l’on commence la simulation par l’action A ou par l’action B.

Si on commence par A, on exécute A, mais A ne déclenche pas B. Le processus B n’est pas encore sensibilisé à la requête provenant de A. La requête émise par A est perdue. Mais on exécute tout de même B parce que celui-ci est candidat à l’exécution du fait de l’initialisation. B s’exécute jusqu’au point de synchronisation du processus avec le noyau. Il se sensibilise sur la requête provenant de A, puis se place en attente d’une requête en provenance de A. Dans ce cas, il n’y pas de coïncidence entre le déclenchement du processus B du fait de l’occurrence de la requête et son déclenchement du fait de l’initialisation. Cela conduit au comportement suivant : 1 pré_calcul_A() ; 2 notification(requête) ; 3 post_calcul_A() ; 4 pré_calcul_B() ; 5 synchronise(requête) ;

Si on commence par B, on exécute B à l’initialisation, puis A qui déclenche B, puis B. Cela conduit au comportement suivant :

1 pré_calcul_B() ; 2 synchronise(requête) ; 3 pré_calcul_A() ; 4 notification(requête) ; 5 post_calcul_A() ; 6 pré_calcul_B() ; 7 synchronise(requête) ; 8 post_calcul_B() ;

De même qu’au paragraphe 2.5.2, la spécification n’est pas respectée. En effet, nous n’avons spécifié qu’un seul comportement et on en obtient toujours deux. Par contre, il n’y a pas de coïncidence fortuite entre l’exécution d’un processus à cause de l’initialisation et son exécution à cause d’une occurrence de requête.

De plus, dans le second cas, non seulement cela ne correspond pas à la spécification, mais les effets de l’exécution de la fonction « pré_calcul_B() » pourraient être indésirables.

2.5.4 Conclusion

Le tirage aléatoire des processus est nécessaire à la sémantique d’exécution des systèmes à événements discrets asynchrones. Sachant que tous les processus sont candidats à l’exécution à l’initialisation, nous voyons que le recours à la sensibilisation statique des processus ne respecte pas la spécification. En fait, elle introduit une confusion entre l’exécution des processus due à l’initialisation et l’exécution des processus due à la sensibilité de ces derniers.

Nous voyons également que le recours à la sensibilisation dynamique produit des comportements multiples. Par contre, il y a un indice permettant de distinguer l’exécution due à l’initialisation, de l’exécution due à la sensibilité des processus. Il s’agit de la perte d’occurrence d’une requête. Dans la suite, on s’appuie sur cette caractéristique pour éliminer les comportements indésirables à l’initialisation.