NOTIONS DE BASE DES SYSTÈMES TEMPS-RÉEL Sujets Concepts de processus/thread concurrents...

NOTIONS DE BASE DES SYSTÈMES TEMPS-RÉEL

Sujets• Concepts de processus/thread concurrents

– Ordonnancement

– Synchronisation (Sémaphores, Exclusion mutuelle)

– Windows NT et la programmation temps réel

• Lectures: Chapitres 3 et 4 (Real-Time Systems, Liu)

INF-1019Programmation en temps réel

Concepts de processus/thread concurrents

• Configuration générale d’un programme temps-réel:• Un programme TR peut être représenté par une boucle

infinie qui effectue le cycle: lecture -> traitement -> sortie -> affichage -> archivage des données.

• Processus/thread concurrents• Distinctions entre programmes, processus et processeur

–Un programme est strictement une séquence d’instructions à exécuter.

–Un processus/thread est aussi une séquence d’instructions à exécuter mais est en plus un environnement (contexte) constitué entre autre d’un identificateur, d’un état, d’informations sur le point d’arrêt (ex: EIP, EBP etc.).

–Un processeur permet l’exécution des processus/thread.


• Processus/thread concurrents• Distinctions entre programmes, processus et

processeur– Selon Geeter (p 42), un processus est une tâche, ou encore une

activité qui du point de vue du microprocesseur consomme des ressources de la machine.

– Ces ressources sont principalement, de la mémoire (une tâche a besoin de mémoire pour tourner) et du temps CPU.



processeur

– Contexte d’exécution des processus

kernel virtual memory

Memory mapped region for shared libraries

runtime heap (via malloc)

program text (.text)

initialized data (.data)

uninitialized data (.bss)

stack

forbidden0

%esp

memory invisible to user code

the “brk” ptr



processeur

– Contexte d’exécution des processus (images mémoire)


• Processus/thread concurrents• Concurrence

–L’utilisation des processus/thread indépendants permettent d’optimiser l’utilisation du CPU. Un processus/thread en attente de données comme un processus de LECTURE peut être mis dans un état BLOCKED jusqu’au moment ou une information devient disponible. Un autre processus peut alors être exécuté.

–Dans une application TR un processus pour la lecture des données s'exécute soit lorsqu'il y a une interruption provenant de cartes d'entrées, soit périodiquement lorsque réveillé par une interruption provenant de la minuterie du système.

–Le processus de traitement des données (calculs et niveaux alarme) peut être réveillé par le processus de lecture.

–Le processus d'archivage des données peut se réveiller lorsque la mémoire tampon est pleine etc.


• Processus/thread concurrents• Ordonnancement

–Afin de pouvoir gérer les processus le système d'exploitation doit pouvoir mémoriser l'état et la priorité des processus. Les différents états d'un processus sont selon Buhr (p 31):

»ACTIF , le processus s'exécute,

»PRÊT, le processus est prêt pour l'exécution (La priorité de ces tâches est inférieure ou égale à la tâche qui est active),

»ENDORMIE (bloqué), le processus est en attente d'événements qui provoqueront son réveil (interruptions, réception de message ou fin de décompte d'une minuterie). Une tâche plus prioritaire que la tâche active peut-être dans cet état.



–État d’un processus/thread



–État d’un processus/thread (mise en file d’attente)



–Un ordonnanceur de tâche (Scheduler) a pour rôle de stopper le traitement de l’activité courante pour en démarrer une autre. C'est lui qui gère le temps CPU et qui décide à quelle tâche (processus/thread) sera allouée la ressource "temps CPU". Trois modes de fonctionnement existent pour l'ordonnanceur. » Temps partagé: l'ordonnanceur alloue le temps CPU à une tâche pour un

temps limité. Cet intervalle de temps est appelé un quantum. Au bout de ce temps l'ordonnanceur reprend le contrôle du CPU, suite à une interruption matérielle provoquée par une minuterie, et lance l'activité suivante.

» Basé sur la priorité : L'ordonnanceur donne le CPU à la tâche PRÊT la plus prioritaire pour un temps infini (Sauf pour les interruptions plus prioritaires). Si cette tâche fait un appel système l'ordonnanceur reprend le CPU et donne le CPU à l'activité PRÊT la plus prioritaire. Ce type de l'ordonnanceur est utilisé dans les systèmes temps "hard" ou le temps est critique car c'est l'activité la plus prioritaire qui tourne à part celles qui attendent un événement qui n'est pas encore arrivé.



–Trois modes de fonctionnement existent pour l'ordonnanceur (suite).

» Tourniquet (round robin): Dans ce cas l'ordonnanceur alloue du temps CPU pour un temps infini , tant qu'une tâche de priorité plus grande ne devient pas prête, comme dans le fonctionnement basé sur la priorité, mais fonctionne en temps partagé à l'intérieur d'un même niveau de priorité (selon Geeter p 44). Ce type d'ordonnancement, est utilisé pour le temps réel "soft", c'est à dire quand la machine a deux usages. Ainsi la machine peut avoir une fonction temps réel (basé sur la priorité) et une fonction moins prioritaire, comme gérer une session avec un opérateur, où le temps partagé suffit.


• Processus/thread concurrents• Ordonnancement (priorité)



– Systèmes TR Soft VS Hard» Les contraintes de temps d’exécution des systèmes TR peuvent être

classées en deux catégories: Hard ou Soft

» Le non-respect d’une contrainte « Hard » peut provoquer une panne complète du système et possiblement une catastrophe.

» Le non-respect d’une contrainte « Soft » peut provoquer une dégradation des performances.


• Processus/thread concurrents• Synchronisation

–La nécessité d'une synchronisation entre les processus/thread découle du fait que sur toute machine, il y a des ressources critiques comme la mémoire principale, le disque dur, l'écran, l'imprimante, etc.

–En fait, à partir du moment où un système est multitâche, et qu'un périphérique ne peut accomplir qu'une seule séquence d'opérations à la fois, pour un seul utilisateur, cette ressource est donc considérée comme critique. Plusieurs stratégies sont utilisées pour implémenter la synchronisation comme les sémaphores, l’exclusion mutuelle.


• Processus/thread concurrents• Synchronisation (Sémaphore)

–Le sémaphore est le mécanisme le plus simple pour la synchronisation de la communication inter-processus. En général un sémaphore est constitué d'un compteur (entier) et de deux opérations appelées "wait" et "signal" (Buhr p32) et d'une file de processus de type FIFO.

–Les sémaphores sont souvent utilisés pour contrôler l'allocation de ressources. Supposons que votre système met à la disposition de vos processus 2 ports de communication.

»Lorsqu'un processus veut utiliser un port il effectue une opération "wait" qui peut être traduite dans ce cas comme "je suis en attente de la disponibilité de la ressource".

»Si le compteur du sémaphore est à zéro, le processus est bloqué et mis dans la queue d'attente du sémaphore car il n'y a pas de ressource disponible.

»Si le compteur est positif, il est décrémenté et le processus peut continuer sont exécution et utiliser la ressource. Lorsque ce processus a fini d'utiliser la ressource, il effectue une opération "signal" indiquant qu'un port est disponible.



–Supposons que votre système met à la disposition de vos processus 2 ports de communication.

»Dans ce cas, si un autre processus se trouve dans la file d'attente, il est sorti de la liste des processus bloqués et devient éligible pour l'exécution. S'il n'y a pas de processus en attente "signal" incrémente le compteur du sémaphore.

»Une autre application des sémaphores est le transfert de données inter-processus. Dans ce cas un processus produit une donnée inscrite dans une zone de mémoire tampon et un autre processus l'utilise. Pour synchroniser leur utilisation de la mémoire tampon, deux conditions doivent être respectées. Le consommateur doit attendre que le producteur ait fini de produire la donnée avant de la lire, et le producteur doit attendre que le consommateur ait fini de lire la donnée avant de la modifiée. Pour implémenter ce type d’échange on doit utiliser deux sémaphores, soit un sémaphore producteur et un sémaphore consommateur (Voir Geeter p36 voir code).



Producteur

attendre(info_consomme)produire info.

liberer(info_produite)

Consommateurattendre(info_produite)

lire info.liberer(info_consomme)


• Processus/thread concurrents• Synchronisation (Exclusion mutuelle)

–Supposons maintenant que la mémoire tampon peut contenir plus qu'une donnée sous forme de file. Ainsi le producteur et le consommateur pourraient écrire et lire les données à un rythme différent.

–Avec une queue FIFO (first in first out) le consommateur lit les données dans le même ordre qu'elles ont été produites.

–Cependant, si les deux processus tentent d'utiliser la zone mémoire en même temps, la structure de la mémoire tampon pourrait être endommagée.

–Les opérations des processus sur la mémoire tampon doivent être exclusive mutuellement, c'est à dire qu'on doit s'assurer que lorsqu'un processus fait une opération sur la mémoire tampon, que l'autre processus attende qu'il ait fini.

–Le terme section critique est utilisé pour identifier la partie de code qui doit s'exécuter en exclusion mutuelle. Dans ce cas un seul sémaphore est utilisé pour réaliser l'exclusion mutuelle. (Buhr p42 voir code).


• Processus/thread concurrents• Synchronisation (Exclusion mutuelle)

–Maintenant que les deux processus peuvent travailler à leur rythme il est fort probable que la mémoire tampon finira soit par être pleine ou vide. On doit donc s'assurer que le producteur entre dans la section critique seulement si la mémoire tampon n'est pas pleine et que le consommateur entre en section critique seulement si la mémoire tampon n'est pas vide.

–Encore une fois, les sémaphores viennent à notre rescousse! (Buhr p 45 voir code). Notez ici que la ligne contenant CS(xxxxx) est une fonction système (D'un système d'exploitation temps réel) qui implémente une section critique (probablement avec un sémaphore).


• Processus/thread concurrents• Gestion des priorités

–Attention au problème d'inversion de priorité (Buhr p 47). » Supposons que votre programme soit composé de trois processus. Le

premier, H à une priorité Haute, le second, M une priorité Moyenne et le troisième B, une priorité Basse.

» Maintenant supposons que le processus H attend sur un sémaphore (wait) et bloque. Le système alloue maintenant l'exécution au processus M, car il a une plus haute priorité que B. Mais le code de M ne signal pas le sémaphore car c'est le travail de B qui attend d’être exécuté, ayant la priorité la plus basse. Le processus H peut rester ainsi bloqué relativement longtemps ce qui pourrait causer des problèmes en situation de temps réel. On peut utiliser les régions critiques pour remédier à ce problème (Geeter p 49).


• Processus/thread concurrents• Queue d’événements

–Quelques fois, un processus doit répondre à plusieurs événements différents ou l'ordre d'arrivée de ces événements ne peut être déterminé à l'avance.

–Dans ce cas, alloué un sémaphore par événement n'est pas la meilleure approche car lorsqu'un processus est en attente sur un sémaphore pour un événement, l'arrivée d'un autre événement sur un autre sémaphore ne réveillera pas le processus en attente (Buhr p 69).

–La queue d'événements permet aux processus de s'envoyer des signaux sans passer par les sémaphores. Une queue d'événements pourrait être comparée à un sémaphore privé appartenant à un processus. Dans ce cas plusieurs processus peuvent "signaler" la queue d'événement, mais seul le processus propriétaire peut attendre ("wait") après celle-ci.

–Lorsqu'un processus exécute un "wait" sur sa queue d'événements, il vérifie en fait si celle-ci contient un message. S'il n'y a pas de message, le processus est bloqué et tombe en attente. Si un message arrive dans la queue d'événements du processus il sera alors réveillé.


• Processus/thread concurrents• Gestion de la mémoire partagée

–Pour que les processus puissent s'échanger de l'information on doit utiliser une zone de mémoire partagée souvent implémentée sous forme de variables globales. L'accès à cette mémoire doit toujours se faire de façon à s'assurer qu'il n'a pas un processus qui écrit dans cette mémoire pendant qu'un autre veut en faire la lecture (Geeter p 51).

–La gestion de la mémoire virtuelle peut causer certains problèmes pour les applications en temps réel. En effet, il peut être désastreux pour le temps de réponse de l'application que le système d'opération exécute un transfert (SWAP) des données de la mémoire RAM vers le fichier d'échange sur le disque dur, pendant que tout les processus du système temps réel soient endormis. Lorsque le processus temps réel se réveillera, le système d'exploitation devra libérer une partie de la mémoire RAM la transférer sur le disque dur pour recopier ensuite les données du processus temps réel en RAM.


• Processus/thread concurrents• Gestion de la mémoire partagée

–La mémoire cache peut affecter aussi le temps "déterministe" d'une application temps réel. Même si l'utilisation de mémoire cache donne un temps d'accès moyen inférieur aux temps d'accès sans mémoire cache, le temps de réponse n'est cependant pas constant. Dans ce cas il faut attribuer le pire cas comme temps de réponse du système.


• Processus/thread concurrents• WINDOWS NT (2000) et la programmation TR

– Même s'il est surtout utilisé dans les applications bureautiques, Windows NT offre certaines fonctionnalités utiles pour les applications en temps réel.

– On le retrouve ainsi dans des applications où auparavant la seule alternative était les systèmes d'exploitation spécialisés ou propriétaires.

– Avec Windows NT, un niveau supplémentaire est apparu dans le domaine du temps réel, en faisant la distinction entre le "soft real time" (temps réel souple) et le "hard real time" (temps réel dur).

– Le temps réel rigide exige un déterminisme de 100% quant au temps de réponse. Le temps réel souple accepte de ne pas avoir 100% de déterminisme (Geeter p 144).

– Windows NT se place dans le domaine du temps réel souple avec un temps de réponse aux interruptions compris entre 1 et 20ms.

– Le noyau multitâche a été conçu pour optimiser le temps de réponse de la majorité des applications. Cependant, sa façon de traiter les interruptions peut causer certains problèmes.



– Ainsi un processus prioritaire peut être interrompu par une interruption provoqué par la souris.

– Cependant, une fois l'interruption enregistrée dans le système, le contrôle reviendra au processus le plus prioritaire.

– On peut palier aux inconvénients du temps réel souple de Windows NT en se procurant des extensions temps réel appelées RTXAPI.

– On peut citer INtime de la société Radisys et RTX for Windows NT de Venturcom.

– Le principe d'utilisation de ces extensions est de séparer la partie temps réel rigide et le partie souple. L'extension s'occupera du temps réel rigide et Windows NT du temps réel souple.



–Voici une description des caractéristiques de Windows NT ayant une incidence majeure pour les applications temps réel.

» Réponse aux événements extérieurs

» Le noyau de Windows NT offre 32 niveaux d'interruption. Ces niveaux aident à prioriser les tâches découlant des interruptions. Lorsqu'une interruption survient, toute exécution ayant un niveau d'interruption plus bas est suspendue et l'exécution de la routine d'interruption plus prioritaire démarre. Si le système roule sur une machine à plusieurs processeurs, un seul processeur sera interrompu pour s'occuper de l'interruption. Les entrée/sortie asynchrones sont un autre mécanisme intéressant pour le temps réel. On peut ainsi lancer une écriture sur le disque sans avoir à attendre que l'appel soit terminé pour continuer l'exécution du programme. Un événement

sera lancé pour indiquer que l'écriture est terminée.




» Ordonnancement et priorité:

» Un niveau de priorité est assigné à chaque processus (une application pour NT). Il y a 32 niveaux de priorité. Un processus possède un ou plusieurs "thread" ( fil d'exécution concurrent).

» Ainsi si un processus est créé avec un niveau de priorité de classe REAL_TIME (niveau de priorité 24) ses "thread" pourront être créé avec un niveau de priorité variant de 22 à 26.

» Chaque "thread " est indépendamment ordonnancé par le noyau. Chaque thread se voit assigné un quantum c'est à dire le maximum temps pendant lequel il peut s'exécuter avant que le système vérifie si un autre "thread" de même priorité est prêt à être exécuter.





» En général un processus REAL_TIME aura priorité sur presque toutes les activités du système.

» Lorsque le CPU devient "libre", le noyau cherche dans la queue ayant la plus haute priorité des thread à l'état "ready". Le noyau retire de la tête de la liste le thread et l'exécute. Cette action se nomme un changement de contexte. La plupart des changements de contexte surviennent lorsqu'un "thread" doit attendre. Cette attente peut être provoquée par une page qui n'est pas dans la RAM, le thread doit alors attendre que le thread de gestion de la mémoire virtuelle traite cette faute de page avant de pouvoir continuer.





» Plusieurs appels au système peuvent mettre explicitement un thread en attente jusqu'à ce que l'événement spécifié survienne. Si un "thread" de haute priorité passe de l'état endormi à l'état prêt suite à un événement, il y aura aussi changement de contexte. Le thread haute priorité va "préempter" un thread de plus basse priorité en exécution.



–Voici une description des caractéristiques de Windows NT ayant une incidence majeure pour les applications temps réel.» Gestion de la mémoire:

» Windows NT implémente un système de mémoire virtuelle. Si un processus demande plus de mémoire RAM et qu'il n'y en a plus de disponible, NT transfère des blocs de mémoire de processus endormi vers le disque dur. Il est cependant possible de bloquer ce transfert pour un processus, ce qui est très utile pour une application temps réel.

» De plus le processus de gestion de la mémoire virtuelle à une priorité plus basse que la priorité REAL_TIME et ne peut donc enlever le CPU à un processus temps réel.



–Voici une description des caractéristiques de Windows NT ayant une incidence majeure pour les applications temps réel.» Gestion de la mémoire:

» Les thread d'un processus partagent le même espace de mémoire virtuelle. Grâce aux fichiers "mappé", NT offre la possibilité de partager la mémoire physique entre des processus différents, même si ceux-ci n'ont pas le même espace d'adressage virtuel. De cette façon l'accès aux données devient très performant.

» La gestion de la mémoire cache, même si elle offre le meilleur temps d'accès en moyenne sur un système d'exploitation "tout usage", introduit un élément non prévisible quant au temps d'accès de la mémoire et est une des causes qui font de NT un système

temps réel "soft".



–Voici une description des caractéristiques de Windows NT ayant une incidence majeure pour les applications temps réel.» Synchronisation:

» Windows NT offre plusieurs objets de synchronisation tels que les minuteries, événements, "mutex", sémaphores, "spinlock" et section critique.


• Processus/thread concurrents• WINDOWS NT (2000) (API WIN32)

–Processus» Les processus Win32 sont inertes. Un processus Win32 n'exécute rien, il

dispose seulement d'un espace d'adressage contenant le code et les données d'un fichier EXE d'une application ainsi que les DLL requises par le programme.

» Pour qu'un processus puisse accomplir une tâche il doit posséder un thread (unité autonome d'exécution). Lorsque vous créez une application Windows, celle-ci contient une fonction appelée WinMain(). C'est suite à cet appel qu'un processus et son thread principal sont créés.

» En fait un processus peut être composé de plusieurs thread, chacun exécutant "simultanément" du code situé dans l'espace d'adressage du processus.

» Ainsi, chaque thread doit posséder son propre jeux de régistres processeur et sa pile. Cette technique est très utile mais amène des problèmes de synchronisation lorsqu'un thread a besoin de voir les résultats d'un autre thread.



–Processus» De plus, s'il y a un bug avec un pointeur dans le code du nouveau thread,

vous pourriez écraser un élément important dans votre espace d'adressage.

» Une autre approche serait de créer un processus enfant. Imaginer que vous devez exécuter une tâche complexe en "parallèle". Un moyen de protéger votre espace d'adressage est de créer un nouveau processus. Pour créer un nouveau processus à partir de cette application on peut utiliser la fonction système CreateProcess() de l'API Win32.

» Malheureusement, le nouveau processus aura certainement besoin d'effectuer certaines opérations sur les données contenues dans votre espace d'adressage. Il serait donc utile que le nouveau processus travaille dans son propre espace et n'ait accès qu'aux données nécessaires de l'espace du processus parent.

» Win32 propose plusieurs méthodes pour transférer des données entre les processus: DDE, OLE, Canaux(pipe), Mailslot, fichiers mappés etc.



–Processus

» Notez cependant que la fonction CreateProcess() prend comme paramètre le nom d'un fichier exécutable et une chaîne de caractères contenant une ligne de commande pour l'exécutable. Donc pour créer une application avec plusieurs traitements concurrents vous devriez créer un exécutable pour chacun des traitements. C'est pour cette raison qu'il est beaucoup plus simple d'avoir une application avec plusieurs threads.



–Thread» Un thread décrit un chemin d'exécution à l'intérieur d'un processus.

» Les threads sont très utiles car ils permettent à une application de continuer à s'exécuter lorsqu'une partie de celle-ci est en attente d'un événement où d'une entrée/sortie.

» Les thread permettent donc une meilleure utilisation du CPU, ce qui est indispensable dans les applications en temps réel.

» Cependant, l'utilisation de threads n'assure pas toujours une meilleure performance de votre application.

» Si le système sur lequel roule votre application est "I/O bound", l'utilisation de threads améliorera les performances de votre application. Mais si votre système est "CPU bound", les performances seront moindres.

» Chaque thread possède sa propre pile dans l'espace d'adressage du processus (4 Go). Ainsi, si vous employez des variables statiques et globales, tout les threads du processus y aurons accès.



–Thread» Les variables locales et automatiques d'un thread sont créées sur sa pile et

se trouvent donc mieux protégées et risque moins d'être endommagées par les autres threads.

» L'API Win32 propose la fonction CreateThread() pour créer de nouveaux threads.

» Un thread peut se terminer de 3 façons. Le niveau de priorité des threads peut être ajusté. Attention aux droits d'accès pour pouvoir changer la priorité.



–Synchronisation des thread» En général, un thread se synchronise avec les autres threads en se mettant

en sommeil.

» Lorsqu'un thread est en sommeil, le système ne lui assigne plus de plage de temps de traitement du processeur.

» Cependant avant de s'endormir le thread informe le système d'exploitation de l'événement qui lui permettra de reprendre son exécution. Les principaux objets de synchronisation de l'API WIN32 sont les suivants.



–Synchronisation des thread

»Les principaux objets de synchronisation de l'API WIN32 sont les suivants:

» SECTION CRITIQUE: La section critique est le mécanisme de synchronisation le plus simple et le plus rapide.

» Cependant elle ne peut être utilisée que pour synchroniser les threads appartenant à un même processus.

» On utilise les sections critiques pour s'assurer qu'un seul thread à la fois pourra avoir accès à certaines données.

» On entre dans une section critique avec la fonction

EnterCriticalSection() et on en sort avec la fonction

LeaveCriticalSection().




»SECTION CRITIQUE:

» Une variable globale de type CRITICAL_SECTION sert pour contrôler l'accès à la section critique. Notez qu'il est possible d'utiliser plusieurs sections critiques pour protéger différentes données.

» Il faut dans ce cas faire attention à l'ordre d'entrée dans des sections critiques imbriquées si on ne veut pas tomber dans une impasse (deadlock).

» Voici une brève description du programme CritSect qui donne un exemple de l'utilisation des sections critiques. Ce programme est composé de trois threads.




»SECTION CRITIQUE:

» Soit le thread principal qui s'occupe de la boîte de dialogue , le thread de la fonction AcqusitionThread() qui simule la lecture d'un signal analogique (0-100%) provenant d'une carte d'acquisition de données et qui incrémente une variable contenant le numéro de la lecture.

» Le thread DisplayThread() lit les variables globales contenant le numéro séquentiel de la lecture et la valeur lue et les ajoutent dans la boîte de dialogue. Les deux variables globales sont protégées par une section critique.




»SECTION CRITIQUE:

» Notez l'utilisation de la fonction Sleep(0) qui sert à indiquer que nous voulons affecter le reste de la plage de temps de traitement à un autre thread afin de simuler ce qui peut se produire si le thread est préempté après avoir pris la lecture et avant d'avoir incrémenter le compteur du numéro de la lecture.

» Si vous ne cochez pas l'option synchronisation et que vous cochez l'option voir Thread compteur et que vous augmentez la priorité du thread d'affichage (et baisser la priorité de l'acquisition) vous trouverez pour un même numéro séquentiel de lecture deux valeurs différentes (Tout de suite après l'affichage Cptr: increment).




»SECTION CRITIQUE:

» Si vous cochez l'option synchroniser, toutes les valeurs serons les mêmes.

» Un autre test intéressant est de lancer une recherche sur le Lecteur C sur tous les fichiers contenant une certaine chaîne de caractères. Exécuter en même temps le programme CritSect avec une priorité de processus normale. Le programme s'exécute et la recherche se poursuit (On entend le disque dur). Changez la priorité à Real Time. On constate ici que notre programme ne laisse pas de temps CPU aux autres processus.




»SECTION CRITIQUE:

» Comme dernière remarque, il faut noter que si la priorité du thread d'affichage est plus basse que celle du thread d'acquisition de donnée, on obtient une fréquence d'acquisition plus élevée. C'est à dire que notre système prend plus de lecture à la seconde, mais ne peut pas toutes les afficher. Si on inverse la priorité relative de ces deux thread, la fréquence d'acquisitions sera plus basse, moins de lectures par secondes, mais on a le temps d'en afficher plus et on peut même aller jusqu'à afficher plusieurs fois la même lecture. On constate donc qu'il est possible de "tuner" le comportement de notre

application avec la priorité des "threads".




» SECTION CRITIQUE (Projet Critsect)

NOTIONS DE BASE DES SYSTÈMES TEMPS-RÉEL Sujets Concepts de processus/thread concurrents...

Documents

Transcript of NOTIONS DE BASE DES SYSTÈMES TEMPS-RÉEL Sujets Concepts de processus/thread concurrents...