• Elles suivent les normes POSIX 1.c ( Pthreads)
Chargées comme modules du noyau
Traitées dans l’ordre dicté par le scheduler en fonction de leurs priorités.
Elles occupent toutes le même espace d ’adressage (celui du noyau!) et se chargent dynamiquement. Attention bobo!
Leurs ressources sont allouées de façon statique

 L'écriture de telles tâches est compliqué car l'erreur n'est pas permise, en effet il faut garder à l'esprit que l'espace d'adressage est celui du noyau. Tout bug est fatal au système.

CAS D'ECOLE

• Le Processus A de priorité 3 prend une ressource.
• Le Processus B de priorité 2 arrive, Le processus A est préempté pour laisser la place à B.
• Jusqu'ici tout va bien c'est le cas classique. Oui mais (parcequ'il faut toujours un mais) Ce que B veut c'est la ressource que A détient. Hors A à été préempté il ne peux donc pas restituer cette resource. Le serpent se mort la queue.

RTL ne permet pas ce genre de situations vis à vis des resources car elles sont allouées de façon statique, rtl_sched sait donc dés le départ si la cohabitation de plusieurs processus est possible et s'il en n'entrainera pas d'interblocages.

EXEMPLE: L'audio processing

L'audio processing regroupe tous ce qui à un rapport avec le travail du son. L'exemple ci dessous décrit la gene occasionée par la préemption du processus de lecture d'un fichier son. Les raies qui s'étendent au dela de la limite horizontale rouge montrent les gènes audibles sous forme de coupures du son un peu comme avec les portables lorsque l'on capte mal...

Il s'agit la d'un OS non temps réel très chargé ou la priorité maximale à été donnée au processus de lecture. On s'aperçoit que malgrés tout des coupures sont audibles.

Avec RTL les choses sont différentes comme nous le montre le schéma ci dessous.

Il n'y à plus de coupure du son car le processus n'a pas été préempté. Alors merci qui?