Systèmes en temps réel Threads et Capsules Optionnels.

Systèmes en temps réel

Threads et Capsules

Optionnels

Capsules optionnels - 2

Synopsis

Modélisation de la concurrence Types de concurrence Quand les utiliser

Modélisation des structures dynamiques Structure interne dynamique Rôles de capsule dynamiques vs statiques

Le service de la classe Frame Exemple


Types Concurrence

Processus Concurrence pesante Un espace d’adresses unique et un environnement

d’exécution unique Peut être sous divisé en un nombre de threads

Thread Concurrence légère Un calcul indépendant qui exécute dans l’espace

d’adresses et d’exécution du processus qui l’englobe

Capsule Une forme de concurrence encore plus légère Exécute dans le contexte d’un thread qui l’englobe Concurrence logique qui a une sémantique d’exécution

jusqu’à la fin


Quand les utiliser

Capsules La majorité des requis en concurrence peuvent être traiter

avec l’utilisation de la concurrence légère des capsules

Threads Si on fait un appel de système qui bloque

tel que la lecture d’un socket Pour les opérations qui demande beaucoup de temps de

CPU Si une section de code est critique et que vous voulez

élever sa priorité par rapport aux autres capsules

Processus Requis pour l’exécution sur différents processeurs

(client/serveur) Pour augmenter la protection de la mémoire / tolérance

des défaillances


Modèle monothread


Modèle multithread


Structure dynamique interne

“ une source commune de complexité dans les systèmes en temps réel, est le besoin de reconfigurer le système durant l’exécution, basé sur les changements dynamiques de l’environnement externe” [1]

Une approche est de dessiner un système fixe (statique) basé sur le scénario du pire cas Ceci va sûrement nous amener à une solution dispendieuse

et inefficace Une autre approche est d’employer une forme de

gestion des ressources, le plus difficile étant la création et destruction dynamique des composantes de système et de leurs relations


Rôles de capsule statiques vs dynamiques

Rôles de capsules fixes Créés et détruits simultanément quand la capsule

contenant est créée ou détruite En gros, toutes les capsules que nous avons vue à

date Rôles de capsule optionnels

Pas créés en même temps que la capsule contenant, mais créés / détruits dynamiquement

Certaines règles: Une capsule optionnelle qui est instanciée doit être une sous

classe compatible à la classification du rôle de la capsule Un rôle de capsule optionnel ne peut être détruit que par

son contenant immédiat


Capsules Optionnelles

Le nombre maximum d’instances de capsules créées dynamiquement est déterminé par la cardinalité (ou facteur de reproductions)


Services de la classe Frame de RoseRT

Fournit les mécanismes pour créer et détruire les capsules optionnelles

Fournit les mécanismes pour créer les threads Classes d’implémentation:

Frame:: {type de classe pour un port de service Frame} incarnate( ), incarnationAt( ), destroy( ), classIsKindOf( ) ,

classOf( ), className( ) RTActorID:: {poigné pour l’instance d’une capsule}

isValid( ) RTActorRef:: {contient l’info commune pour chaque

rôle} size( )


Création dynamique d’un rôle de capsule

framePort.incarnate( capsule_role, [capsule_class], [initialization_data], [type_descriptor], [logical_thread], [index] );

Les threads séparés peuvent seulement être créés via les capsules optionnels

[ dénote les arguments optionnels]


Création dynamique d’un rôle de capsule (2)

Exemple: RTActorID capsuleID;PrinterData myPrintData(14, “printJob05”);capsuleID = anotherFramePort.incarnate(myDeviceRole, // rôle de la capsulePrinter, // classe de la capsule (ou EmptyActorClass)&myPrintData, // données d’initialisation&RTType_PrinterData, // descripteur de typeprinterThread, // nom du thread logique-1 // prochain index disponible);


Destruction dynamique d’un rôle

Frame::destroy(RTActorRef) //capsuleRoleName

et Frame::destroy(RtActorID) //capsuleID

ExemplesframePort.destroy(myDeviceRole); // myDeviceRole à été

créée par le cadre framework avec la relation “d’agrégation”

ouRTActorID myDeviceID = framePort.

incarnationAt(capsuleRole, index); //et par la suiteframePort.destroy(myDeviceID);


Exemple – Jam Controller

Nom de rôle de capsule statique


Exemple Diagramme de Structure

Trois capsulespotentiellement instanciées


Exercice de capsules optionnelles /Threads (voir le modèle ThreadsExercise)

Téléchargez et dézippez le modèle contenu dans “ThreadsExercise.zip”

Chargé et exécutez le modèle et observez son comportement

Étudiez le code contenu dans le model Répondez aux 4 questions


Exercice de Threads– Diagramme de classes


Exercice de Threads - Questions

1. Comment est-ce que les jammers sont créés et détruits? Expliquez.

2. a. Quel est le nombre maximum de jammers? b. Quel est le nombre maximum actifs? Quelle bandes? c. Pourquoi est-ce que les messages pour la bande G

arrivent deux fois plus souvent?3. a. Sur quel thread est ce que SysController exécute? Sur

quel thread les jammers exécutent? Où est-ce que ce dernier thread est définit? b. Quand le JamController bloque (artificiel), que font les

jammers actifs? Et pourquoi? c. Ceci peut être perçu comme un comportement qui est

indésirable, quel changement de design peut-on faire?


Exercice de Threads - Questions(cont’d)

4. Effacez la dépendance (pas seulement sur le diagramme) entre le JamController et un des jammers pour une bande spécifique. Recompilez et observez le comportement.

a. Dans quel énoncé obtenez vous une erreur de compilation? Et pourquoi?

b. Que se produirait-il si la bande fournit par SysController était ‘C’? Quel type de jammer serait créé, si il y en a un?


Références

[1] Selic, Gullekson, Ward, “Real-Time Object Oriented Modeling”, Chapters 6 & 10 Wiley, 1994

[2] RoseRT On-Line Help “C++ Language Guide / C++ Services Library”

[3] RoseRT On-Line Help “C++ Language Guide / Services Library Class Reference”

Systèmes en temps réel Threads et Capsules Optionnels.

Documents

Transcript of Systèmes en temps réel Threads et Capsules Optionnels.