GESTION DE LA CONCURRENCE

Transcription

1 GESTION DE LA CONCURRENCE Architectures et parallélisme On trouve plusieurs types de systèmes embarqués : mono-coeur ; SMP (symetric multiprocessing) ou multicoeur ; NUMA (non-uniform memory architecture). Même dans les architectures mono-coeur, on souhaite souvent exécuter plusieurs activités de manière concurrente. 53

2 GESTION DE LA CONCURRENCE Boucle principale Le schéma le plus simple est celui de la boucle principale : Inconvénients : gaspillage des ressources par l utilisation systématique du polling ; pas de gestion de priorité Pas de fréquence relative. 54

3 GESTION DE LA CONCURRENCE Boucle événementielle On peut également attendre un événement signalé par le matériel : Inconvénients : pas de priorisation des événements ; pas de possibilité de faire de longs calculs sans bloquer la gestion des autres événements. 55

4 GESTION DE LA CONCURRENCE Fonctionnement sur interruptions On peut avoir : une tâche principale qui s exécute en permanence ; des routines lancées lorsqu une interruption survient. C est ainsi que fonctionnent des systèmes monotâche pour «émuler» le multi-tâches (sur interruption de timer par exemple). Inconvénients : une seule tâche principale. 56

5 GESTION DE LA CONCURRENCE Changement de contexte On souhaiterait pouvoir : sauvegarder l état d un traitement donné pour en effectuer un autre et retrouver son état ; effectuer des traitements longs en donnant leur chance aux autres tâches à réaliser. Pour cela, chaque tâche doit disposer de son contexte : l état des registres du processeur dont le pointeur ordinal (program counter) et le pointeur de pile (stack pointer ) ; la pile d appel des sous-programmes, qui doit donc être propre à chaque tâche. 57

6 GESTION DE LA CONCURRENCE Allocation de la pile Dans une architecture multi-tâches, chaque tache i nécessite une pile d exécution. L allocation de cette pile est critique : trop petite, elle causera une corruption mémoire ; trop grande, elle consommera trop de mémoire. La taille à choisir dépend des profondeurs d appel de chaque tâche et de la taille occupée par les variables locales. 58

7 GESTION DE LA CONCURRENCE Synchronisation L utilisation d un système multi-tâches peut poser des problèmes de synchronisation : Si cette routine est appelée deux fois avec les mêmes paramètres simultanément et que le changement de contexte se fait en (1), la vérification peut s avérer incorrecte. Si une autre tâche effectue un total des soldes alors que le changement de contexte s est fait en (2), le total sera inférieur à ce qu il devrait être. 59

8 GESTION DE LA CONCURRENCE Coroutines Les coroutines sont un modèle de parallélisme coopératif : chaque tâche indique (avec yield()) qu elle accepte de donner la main à une autre ; les problèmes de synchronisation n existent pas, les points de synchronisation étant placés par l utilisateur. Certains modèles de coroutines sans pile existent : la consommation mémoire est réduite ; les variables locales sont interdites ; yield() ne peut être appelé que depuis le sousprogramme principal de la coroutine ; sur certaines architectures avec une pile dédiée (PIC18F), le changement de contexte est bien plus rapide. 60

9 GESTION DE LA CONCURRENCE Priorités Les priorités permettent de choisir la prochaine tâche à exécuter : les priorités peuvent être statiques ou dynamiques ; le temps maximum entre deux changements de contexte indique le temps de réaction à une condition extérieure ; on peut créer une idle task de priorité minimale qui met le processeur en veille en attendant qu un événement modifie le système ; cette même idle task peut également effectuer des opérations de nettoyage (agrégation des blocs mémoire libres) ; le passage régulier dans l idle task peut indiquer une non-surcharge du système et servir à signaler un watchdog. 61

10 GESTION DE LA CONCURRENCE Systèmes préemptifs Un système multi-tâches est dit «préemptif» lorsqu une tâche peut être interrompue sans l avoir elle-même demandé (yield) ou autorisé (par un appel au système) : réaction plus rapide à des événements asynchrones ; réveil d une tâche plus prioritaire à l expiration d un délai fixé (alarme) ; possibilité ou non de round-robin entre des tâches de même priorité (quantum de temps) ; nécessité d utiliser des outils de synchronisation pour utiliser des données communes ou communiquer entre les tâches. 62

11 GESTION DE LA CONCURRENCE Section critique Une section critique représente un ou plusieurs chemins de code dans lesquels une seule tâche peut se trouver à la fois. Implémentations possibles : inhibition temporaire des interruptions ; inhibition temporaire de l ordonnanceur préemptif, si les routines d interruption n utilisent pas les données ; utilisation d un verrou, avec ou sans réentrance, avec ou sans héritage de priorité. Dans toutes ces solutions, on risque de bloquer une tâche Prioritaire. 63

12 GESTION DE LA CONCURRENCE Sémaphore Un sémaphore représente un ensemble de ressources et comprend, outre son initialisation, deux opérations : V(), release() ou signal() : créé une ressource, jamais bloquant. P(), take() ou wait() : demande une ressource, et bloque l appelant si aucune n est disponible ; ne revient de l appel que lorsque la ressource a été acquise. Une ressource n appartient à personne. Les opérations de création ou destructions peuvent être effectuées par des threads différents. 64

13 GESTION DE LA CONCURRENCE Verrou Un verrou protège une section critique, et est pris puis libérer par un thread. Seul un thread peut posséder le verrou à un moment donné. En interne, un verrou possède une file d attente contenant les références des threads en attente du verrou. Il est possible d implémenter un verrou à base de sémaphore, mais le verrou est une structure de données plus simple et lorsqu il est pris appartient à un thread. 65

14 GESTION DE LA CONCURRENCE Problème potentiel Imaginons la situation suivante : un verrou X ; une tâche ψ basse de basse priorité acquiert X à t0 ; une tâche ψ haute de haute priorité démarre à t1 et réclame X à t2 ; une tâche ψ medium démarre à t3 (avant que la tâche basse ait relâché X) et dure très longtemps. On peut arriver à une situation où la tâche medium bloque de par sa seule existence la tâche plus prioritaire haute sans pour autant posséder de ressource dont cette dernière a besoin pour progresser. 66

15 GESTION DE LA CONCURRENCE Inversion de priorité L inversion de priorité est une situation dans laquelle une tâche moins prioritaire bloque, indirectement, une tâche plus prioritaire, en empêchant la libération d un verrou. 67

16 GESTION DE LA CONCURRENCE Inversion de priorité L inversion de priorité est une situation dans laquelle une tâche moins prioritaire bloque, indirectement, une tâche plus prioritaire, en empêchant la libération d un verrou. 68

17 GESTION DE LA CONCURRENCE Interblocage Si des tâches utilisent plusieurs sémaphores ou verrous et cherchent à réserver les ressources au même moment, on peut aboutir à des interblocages : un deadlock lorsqu aucune des tâches ne peut progresser ; un livelock lorsque les deux tâches progressent mais passent leur temps uniquement à réserver (et libérer) les ressources. Certains systèmes détectent les situations de deadlock en phase de développement. 69

18 GESTION DE LA CONCURRENCE Synchronisation et interruptions Les routines d interruption (Interrupt Service Routine ou ISR), prioritaires, empêchent la progression normale du programme et limitent la gestion par priorités. On divise généralement le traitement en deux parties : FLIH (first-level interrupt handler), consistant à débloquer une tâche qui effectuera le traitement complet de l interruption et à enregistrer sa prise en compte au niveau matériel ; SLIH (second-level interrupt handler), tâche ordinaire, disposant de sa priorité propre, qui effectue le traitement, possiblement long, de la condition signalée. Un événement peu important sera acquitté rapidement au niveau du matériel mais sera possiblement traité beaucoup plus tard lorsqu il ne restera rien de plus important à faire. 70

19 GESTION DE LA CONCURRENCE Synchronisation et interruptions La signalisation est faite à l aide d un sémaphore S : le FLIH donne le sémaphore : V(S) (non bloquant) ; le SLIH consomme le sémaphore : P(S) (potentiellement bloquant). 71

20 GESTION DE LA CONCURRENCE Différents sémaphores et verrous Dans les systèmes embarqués, on trouve généralement différents types de sémaphores : sémaphores dont le nombre de ressources est plafonné ou non, sans héritage de priorité, utilisé principalement pour la synchronisation (FLIH/SLIH ou entre tâches) ; verrous avec héritage de priorité ; verrous multi-entrées avec héritage de priorité. L opération bloquante P(S) sur une entité S est généralement assortie d un timeout : timeout à zéro : retour immédiat ; timeout non nul : temps d attente limité ; timeout «infini» : appel bloquant. 72

21 EXEMPLES 73

22 EXEMPLES 74

23 EXEMPLES Le système de contrôle des gouvernes de l'airbus A320 est un système embarqué dont les exigences sont : le système doit traduire en ordres de déflection des gouvernes les ordres de pilotage venant du pilote ou de pilote automatique (facteur de charge) Le système doit maintenir l'avion dans son domaine de vol quelles que soient les commandes du pilote ou du pilote automatique Compte tenu de la dynamique de l'avion, les ailerons et la gouverne de direction doivent être asservis à une période minimale de 10ms 75

24 EXEMPLES Compte tenu de la dynamique de l'avion, la gouverne de profondeur doit être asservie à une période minimale de 30ms La perte de contrôle à la fois des ailerons et des spoilers est catastrophique (taux de panne de 10-9 ) La perte de contrôle de la profondeur est catastrophique (taux de panne de 10-9 ) La perte de contrôle des spoilers, des ailerons, de la direction et de la profondeur ne doit pas être causée par une panne unique 76

25 EXEMPLES 77

26 LINUX EMBARQUÉ

27 SYSTÈME EMBARQUÉ ET LINUX Pourquoi retrouve-t-on Linux dans l embarqué? Tout d abord pour ses qualités qu on lui reconnaît maintenant dans l environnement plus standard du PC grand public : Libre, disponible gratuitement au niveau source. Ouvert. Différentes distributions proposées pour coller au mieux à un type d application. 79

28 SYSTÈME EMBARQUÉ ET LINUX Stable et efficace. Aide rapide en cas de problèmes par la communauté Internet des développeurs Linux. Nombre de plus en plus important de logiciels disponibles. Connectivité IP en standard. 80

29 SYSTÈME EMBARQUÉ ET LINUX Linux possède d autres atouts très importants pour les systèmes embarqués : Portage sur processeurs autres que x86 : PowerPC, ARM, MIPS, 68K, ColdFire, Taille du noyau modeste compatible avec les tailles de mémoires utilisées dans un système embarqué (<500 Ko). Différentes distributions proposées suivant le domaine : routeur IP, PDA, téléphone Support du chargement dynamique de modules qui permet d optimiser la taille du noyau. Migration rapide et en douceur pour un spécialiste Linux à Linux embarqué ; ce qui réduit les temps de formation (et les coûts ). 81

30 FACTEURS INFLUANT SUR LE CHOIX D UN OS EMBARQUÉ 82

31 FACTEURS INFLUANT SUR LE CHOIX DE LINUX POUR L EMBARQUÉ 83

32 HISTORIQUE 1999 : Linux embarqué apparaît pour la 1ère fois officiellement à une exposition Linux World Les sociétés Motorola, Force et Ziatech ont présenté un système CompactPCI fonctionnant sous Linux. 84

33 HISTORIQUE 2000 : création du consortium Linux embarqué (Embedded Linux Consortium) dont le but est de centraliser et de promouvoir les développements de solutions Linux embarqué. Ce consortium regroupe : des éditeurs de distributions Linux des éditeurs de systèmes temps-réel propriétaires (comme WindRiver pour VxWorks) des fabricants de composants 85

34 LINUX EMBARQUÉ Linux embarqué est une adaptation du noyau Linux à un système embarqué. Suivant les capacités du système, on retrouve tout ou partie des fonctionnalités du noyau : Moins de services disponibles. Moins de mémoire requise (< 8 Mo). Boot depuis une mémoire ROM (FLASH). Pas de clavier ou de souris requis. Logiciels spéciaux pour piloter les périphériques du système (écran LCD, flash disk, Disk On Chip DOC, touch screen ). 86

35 LINUX EMBARQUÉ Une version de Linux embarqué peut être spécialement configurée pour coller à une plateforme ou application précise : Linux embarqué pour routeur IP. Linux embarqué sur PDA. Linux embarqué pour microcontrôleur sans MMU. Linux embarqué sur processeur et inférieur

36 POINTS FORTS DE LINUX EMBARQUÉ Fiabilité Faible coût Performances Ouverture Portabilité Modularité Adaptabilité Configurabilité 88

37 POINTS FORTS DE LINUX EMBARQUÉ 89

38 POINTS FAIBLES DE LINUX EMBARQUÉ Les drivers Linux pour un périphérique donné ne sont pas toujours disponibles. Le manque de standards : GUI, extensions Temps Réel Le manque d une cohérence marketing. Le manque d outils de qualification d un système sous Linux (tests de conformité de l API POSIX pour le Temps Réel?). Le modèle de la licence GPL mal compris (droits et surtout obligations). 90

39 POINTS FAIBLES DE LINUX EMBARQUÉ Crédibilité de l open-source Support technique Support temps-réel Outils de développement Méconnaissance des licences 91

40 POINTS FAIBLES DE LINUX EMBARQUÉ 92

41 DISTRIBUTIONS LINUX EMBARQUÉ LIBRES Quelques distributions Linux embarqué libres : RTAI RTLinuxFree KURT OpenEmbedded μclinux Embedded Debian Project PeeWee Linux EtLinux 93

42 DISTRIBUTIONS LINUX EMBARQUÉ COMMERCIALES Quelques revendeurs commerciaux en Linux embarqué: Montavista (Montavista Linux) Metrowerks (Creation Suite for Linux) LynuxWorks (BlueCat - BlueCat RT) RedHat (Embedded) FSMLabs (RTLinuxPro) TimeSys (Linux RT) Koan (Klinux) REDSonic (REDICE-Linux) VxWorks (Commercial Grade Linux) 94

43 PRODUITS À BASE DE LINUX EMBARQUÉ Phatnoise PhatBox -- un autoradio avec disque dur D-Link MediaLounge DSM un lecteur multimédia sans fil iriver PMC un lecteur multimedia portable Linksys Wireless-G WRT54G -- Routeur sans fil-g à haut débit 95

44 PRODUITS À BASE DE LINUX EMBARQUÉ Nokia 770 Internet Tablet -- un PDAtablet PC Motorola E un téléphone mobile tribande GSM, GPRS et EDGE Tivo Series 2 -- un magnétoscope numérique TomTom GO -- un navigateur GPS pour automobile 96