Systèmes en temps réel Services de Communication

Systèmes en temps réel

Services de Communication

Communication (partie 1) - 2

Synopsis

Communication Asynchrones

Communication Synchrones Utilisation des communication synchrones

Problèmes communs

Réception de Messages

Invoqué par chrono

Exemple de brouilleur coordonné

Déferrage d’événements


Communications Asynchrones

La capsule qui envoie ne “bloque” pas quand les messages sont en transit

Elle va compléter tous le code de transitions dans la chaîne avant que le(s) message(s) envoyés aient la chance d’être traités

D’autres messages, et autres chaînes de transitions, peuvent même être traités dans l’intérim

Mécaniques: myPort.mySignal( [data] ).send( [priority] ); Voir la classe OutSignal dans la bibliothèque des

Services

optionnel


Communications Asynchrones

On se rappel de la sémantique d’exécution jusqu’à la fin: Quand déclenchée, chaque chaîne de transitions

va “naturellement” exécuter jusqu’à la fin. Tout message(s) envoyé durant l’exécution de

code dans la chaîne de transitions va être mis dans une file par le service de traitement de messages le la bibliothèque de services en temps réel

Les messages à priorité égale seront traité PAPS Les autres messages déjà dans la file (derrière

celui qui à commencé la transition originale) vont être traités avant le(s) nouveau(x) message(s) envoyé(s).


Communications Synchrones -définit

Fournit un moyen de contourner la sémantique normale d’exécution jusqu’à la fin

La capsule qui envoie (invoque) bloque jusqu’à ce qu’une réponse soit reçu (sémantique d’appel de procédure

Le bloque est efficace même contre la réception de messages à plus haute priorités.

Les communications synchrones imbriqués (nested) sont permises, mais pas circulaire


Communications Synchrones -mécaniques

OutSignal.invoke( ) //envoyeur Message replies; Message[] replies =

senderPort.senderSignal( ).invoke(); if (replies[0] != null)

{ code pour traiter une réponse valide }

else {code pour traiter une réponse invalide }

//receveur receiverPort.receiverSignal( ).reply( );


Communications Synchrones – découplage du receveur

Le comportement événementiel de RoseRT assure que les états sont toujours en “mode réception”

Les messages reçus sont traités de la même façon (du côté de la réception) peut importe qu’ils soient envoyés asynchrone ou synchrone Découple l’implémentation du receveur/envoyeur Cependant, pour utiliser cette assurance, il faut

que le receveur envoie une réponse dans tous les cas


Communications Synchrones– invoqué par chrono

La ponctualité pour la capsule qui envoie (ou son thread) peut requérir qu’une invocation bloque seulement pour une période minimum Le receveur peut aussi être trop lent dans sa réponse Les délais de communication peuvent être trop longs Les communications

Donc une invocation peut avoir besoin d’une temporisation optionnel

Aucun mécanisme d’implémentation en RoseRT Retourne seulement une exception si aucune réponse

est reçu


Communications Synchrones -Pourquoi l’utiliser?

Pour contrôler la séquence des événements (changements d’états) exemple: notre coordination de

receveur/brouilleur

Pour assurer la synchronisation exemple: le système de peinture de widget

Pour assurer qu’il n ’y a pas d’interférence entre les threads logiques ou processus (exclusion mutuelle) exemple: une base de données partagée


Communications Synchrones -dangers

Peut amener aux interblocages (invocation circulaire)

Peut mettre en danger la ponctualité sur le thread de la capsule qui envoie

Problèmes de communication multiprocesseurs long délais fiabilité (communications pauvres)


Exemple – un contrôleur GE


Contrôleur


Brouilleur

rxJamPort.Jamming( ).send( );// du code pour actuellement // transmettre de l’énergie FR

Asynchrone:

rxJamPort.Jamming( ).invoke();if (replies[0] != null){ // du code pour actuellement // transmettre de l’énergie FR }else { // abandonne le brouillage}

Synchrone:


Receveur

Asynchrone:{pas de code}

rxJamPort.ack( ).reply( );//notez que la pointe serait noir // dans ce cas.

Synchrone:


Communications Synchrones -problèmes suplémentaires

Invocation – Réponse en présence de chronos

Invocation – Réponse et réponses “longues”

Invocation – Réponse et réponses “délayées”

Voir le fichier modèle: InvokeTest.rtmdl


Modèle: “InvokeReplywithTimers” InvokeReplywithTimers - Capsules

Documents

Systèmes en temps réel Services de Communication