Introduction au systèmes

d'exploitation embarqués
Temps Réel-RTOS

Pr. MOUZOUNA YOUSSEF

 Système Type

while( 1) Big infinity loop that repeates

{
/ * your r epeated code * / Superloop systems periodic events
}

 Software Simple  Faible réactivité.

 Haut déterminisme  Consommation d'énergie élevée.
 Ressources matérielles minimales.
 Système Type
Foreground Interrupt

Foreground/Background
Background
systems Superloop

 Faible déterminisme.
 Grande réactivité
 Plus de ressources Matériel
 Basse consommation énergétique
 Software plus Complexe
 RTOS
Real Time Operationg systems

Operating System. Real Time

System hat takes tasks and execute them
Correct function at Corect Time
every specific time called periodicity
Real Time doesn' t mean f ast

Hard Real Time Soft Real time

Task 1
Multitasking
CPU
Task 2 lié à la vie humaine lié à une perte d'argent
 système de défense  Jeux vidéo, etc.
antimissile
 Airbag
Task 3
 Système d´exploitation temps réel?

Real Time OS

Systèmes dans lesquels l'exactitude du système Multi-tasking (Scheduler) + Services:

dépend non seulement du résultat logique du Inter Task communication
calcul, mais également du moment auquel les Task synchronization
résultats sont produits. Managing resources

Those systems in wich the correctness of the system depends

not only on the logical result of the comuptation, but also on
the time at wich the results are produced.
[Link]. “Misconceptions About Real-Time Comuting” IEEE Comupter 21(10), October.
1988
 Système d´exploitation temps réel?
 Un RTOS est un programme qui ordonnance l'exécution des tâches de façon ponctuelle par la gestion des
ressources et du temps, et fournit les éléments de base pour développer les applications

 l´Application est souvent divisée en multiple Taches/Tasks

 Le fonction d´un RTOS est d´executer la tache la plus importante « Ready to Run »

 Dans un system a un seul CPU, juste une seule Tache s´execute a chaque instant

 souvent organisé autour

 d'un noyau fournissant les algorithmes minimum pour l'ordonnancement et la gestion des ressources

 de services, fournis par exemple par des modules, pour gérer les systèmes de fichier, les accès réseau, ou
tout autre service requis par l'application
 Système d´exploitation temps réel?
  Système d´exploitation temps réel?

Haute priorité Taches qui sont sans l´etat : Ready to Run Faible priorité

Task Task Task

Code+Data+Stack Code+Data+Stack Code+Data+Stack

Events
Signal/ Messages des autres tasks
Ou ISR
Sélectionner la haute
RTOS priorité
( Code)

CPU
8. 16, 32 ou 64 bits
 Avantages d´utilisation d´un RTOS
 Vous permet de diviser et de prioriser le code de l'application
 Le RTOS exécute toujours la tâche la plus prioritaire qui est prête
L'ajout de tâches de faible priorité n'affecte pas la réactivité de tâches hautement prioritaires

 Les tâches attendent les événements

 Évite les POLLING

 Les RTOS facilitent l'ajout de composants middleware:

 Pile TCP/IP
 Piles USB
 Système de fichiers
 Interface utilisateur graphique (GUI) ……….
 Avantages d´utilisation d´un RTOS
 Crée un cadre pour développer des applications

 Il est possible de respecter tous les délais d'une candidature

 L'analyse monotone de taux (RMA- Rate Monotonic Analysis) pourrait être utilisée pour
déterminer l´ordonnacement

 La plupart des RTOS ont subi des tests approfondis

 Certains sont certifiables par des tiers, voire certifiés (DO-178B, IEC-61508, IEC-62304, etc.)
 Il est peu probable que vous trouviez des bugs dans les RTOS

 Les RTOS prennent généralement en charge de nombreuses architectures CPU différentes

 Très facile d'ajouter la gestion de l'alimentation

 Incovenients d´utilisation d´un RTOS
 Le RTOS lui-même est du code et nécessite donc plus de Flash
 Généralement entre 6 et 20 000 octets

 Un RTOS nécessite de la RAM supplémentaire

 Chaque tâche nécessite sa propre pile
o La taille de chaque tâche dépend de l'application
 Chaque tâche doit se voir attribuer un bloc de contrôle de tâches (TCB)
o Environ 32 à 128 octets de RAM
 Environ 256 octets pour les variables RTOS

 Vous devez attribuer des priorités de tâches

 Décider de la priorité à donner aux tâches n'est pas toujours anodin

 Les services fournis par le RTOS consomment du temps CPU

 La surcharge représente généralement 2 à 10 % des cycles du processeur
 Système d´exploitation temps réel?
 Tous les comportements dans RTOS doivent être déterministes

 certains calculs/décisions ont des délais / Deadlines

 une réponse tardive est une mauvaise réponse

 temps réel ne veut pas nécessairement dire très vite

 lorsque les délais sont respectés, c'est le temps réel

 3 types de délais
 Hard deadline : un delai manquant est dangereuse et conduit à un échec total
 Firm deadline : un manque rend la valeur du calcul inutile, mais ne cause pas de dommages
sérieux
 Soft deadline: le non-respect d'un délai ne cause pas de dommages sérieux
 Système d´exploitation temps réel?
les composants de base du noyau d'un OS Temps Réel sont :

 l'ordonnanceur, contenu dans tous les noyaux et qui va fournir les algorithmes de base pour choisir la
tâche qui va accéder au processeur

 des objets du noyau pour aider les développeurs à créer les applications : tâches sémaphores files de
message...

 des services, qui sont les opérations effectuées par le noyau sur un objet ou plus généralement des
opérations comme les mesures de temps, la gestion des interruptions, la gestion des ressources...
 Caractéristiques d'un OS Temps Réel?
5 propriétés essentielles
 fiabilité (reliability)

 faculté de pouvoir être utilisé sans intervention extérieure

 s'exprime en fonction du nombre de 9 de la disponibilité:

 va dépendre du hardware autant que du software

a un coût certain...
 Caractéristiques d'un OS Temps Réel?
5 propriétés essentielles

 prédictabilité (predictability)
 spécifique des systèmes temps réels
 spécifie le degré de confiance que l'on peut avoir dans la prévision du temps de réponse

 performances
 caractérise la vitesse à laquelle le système va fournir sa réponse
 dépend du hardware autant que du software

 compacité de l'empreinte (compactness)

 utilisation optimale des ressources

 possibilité d'appliquer un facteur d'échelle (scalability)

 utilisation optimale des ressources en cas de modification de la taille du système
 optimisation des conditions de développement
 Tout RTOS doit avoir certaines propriétés souhaitables.
 Comme le RTOS est intégré à l'application, il fonctionne comme un système embarqué compact,
principalement sur le Firemware et la mémoire sans aucun disque dur externe. L'espace mémoire
occupée par RTOS doit être très petit.

 L'application intégrée et le RTOS doivent fonctionner sur différentes plates-formes matérielles avec
différentes architectures de processeur. Par conséquent, le RTOS doit prendre en charge différents
processeurs.

 Le RTOS doit fournir une API standard et des outils de débogage. En effet, RTOS est intégré à
l'application. Le débogage doit être transparent sur l'ensemble du système.
 Classification des RTOS

RTOS à noyau RT
 Généralement conçu pour la rapidité de réponse.
 Peut être inadapté aux systèmes complexes, car priorisation de la rapidité sur la prédictibilité
 En général propriétaire : QNX, PDOS, VCOS, VTRX32, VxWORKS

SE standard à noyau non-RT modifié

 Extension RT gère l’exécution des tâches et considère le noyau standard comme l’une d’elles pour les r
éponses en temps réel
 Interface de programmation d’applications (API) standard versus dédiés
 p. ex. POSIX extension-RT d’Unix, ITRON, OSEK
 Architecture and Organization

Real Time Operating Systems organization

 Task / Tache
 Pour chaque Tache :
 vous attribuez une priorité en fonction de son importance
 nécessite sa propre pile
 gère ses propres variables, tableaux et structures Périphéries E/S
typiquement une boucle infinie
gère éventuellement les périphériques d'E/S
contient votre code d'application
Optionnel

Tache
(Priorité)

Pile
(RAM) variables, tableaux
et structures
 Création des Tasks / Taches
 Pour chaque vous devez informer le RTOS de l'existence d'une tâche :
le RTOS fournit une API spéciale : XtaskCreate() ou équivalent
 Le RTOS assigne la tâche :
son propre ensemble de registres CPU Périphéries E/S
un bloc de contrôle des tâches:
Registres CPU
Optionnel

Tache
(Priorité)

Pile
(RAM)
TCB variables, tableaux
( RAM) et structures
  Création des Tasks / Taches: Considération a prendre en compte
Décomposez le problème en tâches, en respectant les exigences de planification et les réponses en temps réel
nécessaires. Certaines des règles empiriques à prendre en compte dans la décomposition des tâches sont les suivantes
.
 Identifiez une tâche différente pour chaque manipulation de périphérique différente ou pour différentes
fonctionnalités.

 Encapsulez les données et les fonctionnalités dans une tâche responsable.

 Un plus grand nombre de tâches offrent un meilleur contrôle du temps de réponse global. Cependant:
Plus de tâches signifie plus de partage de données, donc plus de soucis de protection et de longs temps de
réponse en raison des frais généraux associés.
Plus de tâches signifie une messagerie inter-tâches, avec une surcharge due aux files d'attente, à la boîte aux
lettres et à l'utilisation de canaux.
Plus de tâches signifie plus d'espace pour les états de tâches et les messages.
Plus de tâches signifient des changements de contexte fréquents (surcharge) et moins de débit.
Plus de tâches signifient des appels fréquents aux fonctions RTOS.
  Création des Tasks / Taches: Considération a prendre en compte
Création de Tache sous FreeRTOS:

xTaskCreate( Task1, //Pointeur sur la fonction implantant la tache

``Tache 1``, //chaine de caractères associes a la tache (nom)
configMINIMAL_STACK_SIZE, // Taille de la pile associe a la tache
pvParametersTask1, //Paramètres passé a la tâche
tskIDLE_PRIORITY+1, //Priorité associe a la tâche
NULL,); //``handler`` pour la gestion de la tache

Exemple:
 Etat des Taches

Blocking/ waiting

Suspend Running

Ready
 Les RTOS sont preemptifs
 Les interruptions

 Souvent, les interruptions sont des événements que

les tâches attendent
 Les interruptions sont plus importantes que les
tâches
 En supposant, bien sûr, que les interruptions
soient activées
 ISR Kernel Aware (KA) :
 Nécessité d'informer le RTOS de l'entrée et de
la sortie de l'ISR
 Permet d'imbriquer les ISR et d'éviter la
planification multiple
 Changement de contexte
Un changement de contexte se produit lorsque le RTOS décide d'exécuter une autre tâche

Tache a exécuter Tache Suspendu

 Priorité
chaque tache se voit attribuer une priorité qui est fonction de son caractère critique. Plus une tache est importante, plus sa
priorité est élevée. Il existe deux types de priorité de taches :

Priorité statique : la priorité de chaque tâche n'évolue pas durant l'exécution. Chaque tache reçoit une priorité fixe lors
de sa création. Toutes les taches et leurs contraintes temporelles sont connues à la compilation.

Priorité dynamique : La priorité de chaque tache peut évoluer durant l'exécution. Cette caractéristique des RTOS permet
d'éviter l'inversion de priorité.

Inversion de priorité
L'inversion de priorité est un problème qui survient lorsqu'une tache est suspendue dans l'attente d'une ressource contrôlée
par une tache moins prioritaire. Par exemple, s'il existe deux taches T1 et T2 avec T1 plus prioritaire que T2. T1 attend
qu'un événement se produise dans T2 (par exemple la libération d'un sémaphore). Dans ce cas, la priorité effective de T1
est réduite à celle de T2 car elle est en attente d'une ressource détenue par T2.
Pour résoudre ce problème, il suffit d'élever temporairement le priorité de T2 en la rendant égale à celle de T1 pendant le
laps de temps qu'elle utilise la ressource en ensuite de restaurer sa priorité normale.
 Priorité
 Problème d´inversion de Priorité
Soient trois tâches TaskA (haute priorité), TaskB et taskC (Basse priorité) et R une ressource partagée par les trois tâches.
Supposons que TaskC est en possession de la ressource R ; TaskC est préemptée par TaskA plus prioritaire, lorsque TaskA
souhaite prendre la ressource R elle sera bloquée à cause de la non disponibilité de R (déjà pris par TaskC), dans ce cas TaskB
peut être exécutée si elle est prête. Ce phénomène est appelé inversion de priorité.
 Problème d´inversion de Priorité
Pour pallier ce défaut, on attribue à la tâche en possession de ressource (TaskC), la priorité de la tâche la plus prioritaire des
tâches demandant la ressource (héritage de priorité). Dans ce cas, lorsque TaskA est bloquée, c’est la TaskC qui reprend son
exécution et non pas TaskB (TaskC à la même priorité que TaskA). TaskC revient à sa priorité ordinaire quand elle sort de la
section critique (libère la ressource).
 Les fils d´attentes / Queue

Une file d'attente (appelé Queue en anglais) est un objet permettant la communication synchrone ou asynchrone
de valeurs entre des taches. Autrement, elle est employée pour envoyer des messages entre les tâches.

Une fil d'attente est une sorte de tampon/ Buffer FIFO qui contient des éléments de données de taille fixe. De
plus, le nombre d'éléments qu'une file d'attente peut contenir est également fixe, après son initialisation.
Habituellement, les tâches écrivent les données à la fin du tampon et les lisent à partir du début du tampon. Mais
il est également possible d’écrire au début. Plusieurs écrivains et lecteurs peuvent écrire et lire à partir du
tampon.
 Les fils d´attentes / Queue

Queue
Tache A Tache B

Une file d´attente est crée pour permettre a deux taches A et B de communiquer, lorsque la file d´´attentes est crée
, elle ne contient aucune valeur, elle est vide

Queue
Tache A 20 Tache B

La tache A envoie ( écrit) une valeur a l´arriere de la fils d´attentes, comme la file d´attentes est vide , elle donc la
seule valeur dans la file , et est donc elle est a la fois a l´arriere et a l´avant de la fils.
 Les fils d´attentes / Queue
Queue
Tache A 15 20 Tache B

La taches A envoie une autre valeur sur la file d´´attentes , elle est écrite a l´arriere de la file immédiatement après
l´ancien valeur que reste a l´avant de la file d´attentes.

Queue
Tache A 15 20 Tache B

La tache B lit a partir de la fils d´attentes, la valeur reçu par la tache B est la valeur a partir de l´avant de la file
d´attentes , qui est la premier la valeur écrite par la Tache A.
Queue
Tache A 15 Tache B

La tache B supprime la valeur lu, ne laissant que la valeur écrite par la tache A dans la file d´attentes, et cette
valeur sera la nouvelle valeur prête a etre lu .
 Les fils d´attentes / Queue : Blocage ne lecture

 Blocage des lectures possible dans les scénarios suivants :

 Si plusieurs tâches sont prêtes à recevoir des données de la file d'attente de messages, la tâche la plus
prioritaire lit les données en premier et la tâche la moins prioritaire lit les données à la fin. Pendant ce temps,
d’autres tâches restent bloquées. On peut également préciser le temps maximum de blocage d'une tâche lors
de l'envoi d'une requête de lecture. Mais différentes tâches peuvent également avoir des temps de blocage
différents.

 L'autre cas possible est celui où une file d'attente est vide. Dans un tel cas, toutes les demandes de lecture
passent dans un état bloquant. Une fois que les données sont disponibles dans la file d'attente des messages
(lorsqu'une autre tâche place les données dans la file d'attente ), tous les lecteurs vont passés à l'état prêt en
fonction de leur priorité.
 Les fils d´attentes / Queue : Blocage en écriture

 Blocage des écritures en file d'attente

 Tout comme lors de la lecture d'une file d'attente, une tâche peut éventuellement spécifier un temps de
blocage lors de l'écriture dans une file d'attente. Dans ce cas, le temps de blocage est la durée maximale
pendant laquelle la tâche doit rester dans l'état Bloqué pour attendre que de l'espace soit disponible dans la file
d'attente si celle-ci est déjà pleine.

 Les files d'attente peuvent avoir plusieurs rédacteurs, il est donc possible qu'une file d'attente pleine contienne
plusieurs tâches bloquées en attente de terminer une opération d'envoi. Lorsque tel est le cas, une seule tâche
sera débloquée lorsque l'espace dans la file d'attente sera disponible.

 La tâche débloquée sera toujours la tâche la plus prioritaire en attente d'espace. Si les tâches bloquées ont la
même priorité, alors ce sera la tâche qui attend le plus d’espace qui sera débloquée.
 Gestion des ressources et communication entre taches

 Problématique

 Le transfert correct de données entre taches dans un programme temps-réel soulève des problèmes
plus importants que dans le cas d'un programme unique communiquant avec des routines
d'interruption car :

 chacune des taches peut voir son exécution suspendue après chaque instruction afin de transférer
l'usage du processeur à l'autre tâche,
 les changements de contexte ne peuvent être évités qu'en interagissant avec l'ordonnanceur.

 Pour communiquer entre différentes taches, le noyau fourni des services destinés à :

 assurer la synchronisation des taches communicantes,

organiser le transfert de données d'une tache à l'autre.
 Gestion des ressources et communication entre taches
 Semaphore

le sémaphore est une variable ou un type de données abstrait utilisé pour contrôler
l'accès à une ressource commune par plusieurs processus et éviter les problèmes de
section critiques dans un système concurrent tel qu'un système d'exploitation
multitâche

il agit comme un mécanisme de communication et de synchronisation inter-processus

 Gestion des ressources et communication entre taches
 Utilisation du sémaphore

 Gestion des ressources partagées

 Synchronisation des tâches

Outre la gestion des ressources partagées, la synchronisation des tâches peut également être effectuée à
l'aide d'un sémaphore. Dans ce cas, le sémaphore sera comme un drapeau et non une clé.

 Rendez-vous unilatéral
Il s'agit d'une synchronisation à sens unique qui utilise un sémaphore comme indicateur pour signaler
une autre tâche.

 Rendez-vous bilatéral
Il s'agit d'une synchronisation bidirectionnelle effectuée à l'aide de deux sémaphores. Un rendez-vous
bilatéral est similaire à un rendez-vous unilatéral, sauf que les deux tâches doivent se synchroniser l'une
avec l'autre avant de continuer.
 Gestion des ressources et communication entre taches
 Problèmes de section critique
la section critique est une section de code où les variables partagées peuvent être traitées

une action atomique est requise dans une section critique, c'est-à-dire : un seul processus peut s'exécuter
dans une section critique à la fois. Tous les autres processus doivent attendre pour s'exécuter dans leur
section critique
Do
la section d'entrée gère l'entrée dans la Entry section
section critique. Il acquiert les ressources
nécessaires à l'exécution du processus. La Critical section
section de sortie gère la sortie de la
section critique. Il libère les ressources et
Exit section
informe les autres processus que la section
critique est libre
Remainder section

While(true)
 Gestion des ressources et communication entre taches
 Atomic action

une action atomique, c'est-à-dire : un seul processus peut s'exécuter dans une section critique à la fois.
Tous les autres processus doivent attendre pour s'exécuter dans leur section critique

Il y a 2 action atomic:
 Wait(s) _ P(s) : Proberen qui veut dire Test
Cette opération teste la valeur du sémaphore et, si elle est fausse, la définit sur vrai.
 Signal(s) _ V(s): Verhogen qui veut dire Incrément
l'opération du signal définit la valeur sur false

Wait(s) { Signal(s) {
while(S<0=) S++ ;
; // busy wait }
S--; }
 Gestion des ressources et communication entre taches
 Semaphore
Def: le sémaphore est une technique permettant de synchroniser deux ou plusieurs concurrents pour les
mêmes ressources. Lorsqu'une tâche souhaite utiliser une ressource, elle demande le sémaphore et sera
allouée si le sémaphore est disponible. Si le sémaphore n'est pas disponible, alors la demande
demandeuse passera à l'état bloqué jusqu'à ce que le sémaphore devienne libre.

Considérez une situation où il y a deux personnes qui veulent partager un vélo. À la fois, une seule
personne peut utiliser le vélo. Celui qui a la clé du vélo aura la chance de l'utiliser. Et lorsque cette
personne donne la clé à la 2ème personne, alors seule la 2ème personne peut utiliser le vélo.

Le sémaphore est comme cette clé et le vélo est la ressource partagée. Chaque fois qu'une tâche veut
accéder à la ressource partagée, elle doit d'abord acquérir le sémaphore. La tâche doit libérer le
sémaphore après avoir terminé avec la ressource partagée. Jusqu'à ce moment, toutes les autres tâches
doivent attendre si elles ont besoin d'accéder à une ressource partagée car le sémaphore n'est pas
disponible. Même si la tâche essayant d'acquérir le sémaphore est d'une priorité plus élevée que la tâche
acquérant le sémaphore, elle sera en état d'attente jusqu'à ce que le sémaphore soit libéré par la tâche de
priorité inférieure.
 Gestion des ressources et communication entre taches
 Binary Semaphore

la valeur du binaire est limitée à 0 et 1. dans ce type de sémaphore, l'opération d'attente ne fonctionne
que si sémaphore=1, et l'opération siganl réussit lorsque sémaphore=0.
 Gestion des ressources et communication entre taches
 Binary Semaphore

 Utilisation pour la protection de la section critique.

Le sémaphore peut désormais être utilisé pour protéger une ressource critique, comme le démontrent les deux
fragments de code

La tâche qui exécute la ou les attentes en premier aura accès à la section critique. La deuxième tâche se
bloquera, attendant que l'autre tâche exécute le signal. Par la suite, cela pourra également se poursuivre.
 Gestion des ressources et communication entre taches
 Binary Semaphore

 Utilisation pour la synchronisation des proces.

On peut utiliser le sémaphore d'une manière légèrement différente pour forcer l'ordre d'exécution de plusieurs
tâches asynchrones. Pour le cas de base, considérons une application avec deux de ces tâches, T0 et T1, qui
coopèrent sur une partie de l'application. La tâche T0 contient une fonction f(s0) et la tâche T1 contient une
fonction g(s1). Leur ordre d’exécution est crucial ; la fonction f(s0) doit être exécutée avant g(s1). Pour réaliser
une telle synchronisation, nous définissons la synchronisation du sémaphore et l'initialisons à TRUE. Les
fragments de code suivant illustrent la conception.

Notez que, comme la synchronisation est initialisée à TRUE, T1 n'exécutera g(s2) qu'après que T0 aura exécuté
l'instruction f(s1).
 Gestion des ressources et communication entre taches

 Sémaphore

S1

Task 2() {
Task 1() { Task 3() {
………
………
Sem_take(1);
Sem_take(1); ………
Compute;
Compute; Sem_give(1);
………
……… ………
Sem_give(1);
……… }
………
}
}
 Counting semaphore

Le sémaphore de comptage est un outil de synchronisation utilisé dans les systèmes d'exploitation pour contrôler
l'accès aux ressources partagées. C'est un type de sémaphore qui permet à plus de deux processus d'accéder
simultanément à la ressource partagée. Un sémaphore de comptage est représenté par une valeur entière qui peut
être incrémentée ou décrémentée par les process.
La principale différence entre les sémaphores binaires et les sémaphores de comptage est que les sémaphores
binaires ne peuvent prendre que deux valeurs, indiquant soit qu'une ressource est disponible, soit indisponible,
tandis que les sémaphores de comptage peuvent prendre plusieurs valeurs, indiquant le nombre de ressources
disponibles.
 Counting semaphore : principe de fonctionnement.

 Initialisez le sémaphore de comptage avec une valeur qui représente le nombre maximum de ressources
accessibles simultanément.
 Lorsqu'un processus tente d'accéder à la ressource partagée, il tente d'abord d'acquérir le sémaphore en
utilisant la fonction `wait()` ou `P()`.
 La valeur du sémaphore est vérifiée. S'il est supérieur à zéro, le processus peut se poursuivre et la valeur du
sémaphore est décrémentée de un. S'il est nul, le processus est bloqué et ajouté à une file d'attente de
processus en attente.
 Lorsqu'un processus a fini d'accéder à la ressource partagée, il libère le sémaphore en utilisant la fonction
`signal()` ou `V()`.
 La valeur du sémaphore est incrémentée de un et tous les processus en attente sont débloqués et autorisés à
se poursuivre.
 Plusieurs processus peuvent accéder simultanément à la ressource partagée tant que la valeur du sémaphore
est supérieure à zéro.
 Le sémaphore de comptage permet de gérer l'accès aux ressources partagées et de garantir que les conflits
sont évités, tout en permettant à plusieurs processus d'accéder à la ressource en même temps.
 Counting semaphore :

Exemple:

S= 4

Wait() Signal()
Wait() S=1 Wait()
S=2 Wait()
S= 3 S=0
S=1

Process/Thread P1 P2 P3 P4 P5
 Gestion des ressources et communication entre taches
 Muetx

 Un concept similaire lié au sémaphore binaire est le Mutex. une différence clé entre les deux est que le
processus qui verrouille le Mutex (définit la valeur sur zéro) doit être celui qui le déverrouille (définit la
valeur sur 1). dans les contrats, il est possible qu'un processus verrouille un sémaphore binaire et qu'un autre
le déverrouille.

 le mutex est similaire aux principes du sémaphore binaire avec une différence notable : le principe de
propriété. la propriété est le concept simple lorsqu'une tâche verrouille (acquiert) un mutex, elle seule peut le
déverrouiller (libérer). si une tâche tente de déverrouiller un mutex, elle n'a pas été verrouillée (elle n'en est
donc pas propriétaire). alors une condition d'erreur est rencontrée et, plus important encore, le Mutex n'est
pas déverrouillé.
 Gestion des ressources et communication entre taches

 Mutex

Task 1() { Task 2() {

……… ………
Mutex_take(); Mutex_take();
Compute; Compute;
……… ………
Mutex_give(); Mutex_give();
……… ………
} }
 Différence entre Muetx et Binary Semaphore

Sémaphore binaire Mutex

basée sur un mécanisme de signalisation basée sur un mécanisme de verrouillage

le thread/processus qui a une priorité plus élevée que le le thread/processus qui a acquis le mutex ne peut
thread actuel peut également libérer un sémaphore libérer le mutex qu'à la sortie de la section critique
binaire et prendre le verrou
la valeur du sémaphore est modifiée en fonction des La valeur Mutex peut être modifiée comme verrouillée
opérations wait() et signal() ou déverrouillée

Plusieurs threads peuvent acquérir le sémaphore binaire un seul thread peut acquérir le Mutex à la fois
à la fois simultanément

le sémaphore binaire n'a aucun propriétaire la propriété est associée au mutex car seul le
propriétaire peut libérer le mutex

Il est plus rapides que Mutex car n'importe quel autre ils sont plus lents que les sémaphores binaires car seul
thread/processus peut déverrouiller le sémaphore le thread/processus qui a acquis doit libérer le
binaire déverrouillage