Seminar: Mobile Geräte QNX Einführung

Transkript

1 Seminar: Mobile Geräte QNX Einführung Vortragender: Alex Maurer 2010/2011 Philipps Universität Marburg

2 Echtzeitbetriebssystem QNX QNX ist ein RTOS (Real Time OS) vorhersagbares Zeitverhalten niedrige Latenz für Interrupts und bei Thread-Switching Entwicklung seit 1980/82

3 QNX ist vielfältig einsetzbar Zertifizierungen: EAL4+ SIL3 POSIX2003 und andere Plattformen: x86 SH-4 PowerPC MIPS ARM und andere QNX kann sowohl auf kleinen embedded- Rechner mit ganz wenig Speicher eingesetzt werden als auch auf Desktop Systemen als auch auf verteilten Nodes Häufig in Überwachungssystemen von Industrieprozessen, im Automobilbereich und bei Robotersteuerungen eingesetzt RIM hat BackBerrys Tablets mit QNX als OS angekündigt

4 Microkernel (1) QNX hat einen kleinen Microkernel Treiber sind nicht integriert Selbst der Prozessmanager läuft außerhalb des Kernels

5 Microkernel (2) Da viele Komponenten außerhalb des Kernel- Space laufen, ist es unwahrscheinlicher, dass Fehler im Kernel selbst auftretten können Treiberprogrammierer können ihre Treiber einfacher debuggen Der Microkernel kümmert sich vor Allem um Scheduling und Message Passing

6 Threads In der aktuellen Version unterstützt QNX Threads Threads erlauben schnelleren Wechsel bei Parallelverarbeitung Threads eines Prozesses können auf SMP Systemen echt parallel laufen Synchronisierung nötig, wenn Daten zwischen den Threads ausgetauscht werden sollen

7 Synchronisierung (1) In QNX stehen mehrere Konstrukte zur Synchronisierung der Vorgänge zwischen den Threads: Mutexe - Locks, um globale Vars ändern zu können Semaphores - wie Mutexe, nur können n>1 Ressourcen den Lock gleichzeitig bekommen Reader/Writer Locks - sorgen für exklusive Schreibbzw. für Read-only-Locks

8 Synchronisierung (2) SleepOn Locks - Thread blockiert und wird erst wieder aufgeweckt, wenn ein anderes signalisiert, dass die Variable verändert wurde. Zusätzlich wird das Ändern der Variable durch einen Mutex abgesichert Conditional Vars - das Selbe wie vorheriges, nur kontrolliert man selber den Mutex

9 Message Passing (1) Die Kommunikation zwischen den Prozessen erfolgt in QNX vornehmlich durch Message Passing Als Ziel einer Nachricht muss man folgendes angeben: Node-ID (damit kann man gleich direkt die Anfragen über das Netzwerk verschicken!) Prozess-ID Channel-ID (ein Prozess kann unter mehreren Channels auf Anfragen warten) Typischerweise hat man Client-Server Hierarchie

10 Message Passing (2) Der Server bereitet sich auf den Empfang mit recieve(), was ihn blockiert (passives Warten in der blocked-queue des Schedulers) Nach abschicken einer Anfrage mit send() ist der Client blockiert Der Server wird durch die Anfrage aktiviert und kann die Anfrage des Clients abarbeiten und mit reply() antworten Neben blockierenden Nachrichten gibt es zusätzlich die nicht-blockierende Pulses. Außerdem gibt es immer noch die (POSIX-)Signale

11 Scheduling & Prioritäten (1) Scheduling in RTOS/QNX ist anders geregelt, als man zunächst annehmen würde Das oberstes Prinzip ist immer: solange ein Thread mit einer höheren Priorität in der active-queue des Schedulers existiert, wird ein Thread mit niedrigeren Priorität überhaupt nicht zum Laufen kommen Für die Entscheidung, wer von zwei Threads, welche die gleiche Priorität haben, laufen darf, gibt es vor allem diese zwei Algorithmen: Round-Robin (RR) - Jedes Thread bekommt eine Time-Slice, welche dieser zuerst laufen darf, danach kommt der andere Thread dran.

12 Scheduling & Prioritäten (2) FIFO - Der Thread, der als erstes gestartet wurde, wird ewig laufen, wenn dieser nicht die Macht selbst abgibt (sched_yield() oder Wechsel in den blockierten Zustand) Es gilt weiterhin: Wird ein Thread mit einer höheren Priorität aktiv, so verdrängt dieser das bisher gelaufende Thread (Preemption) Interrupts unterbrechen natürlich die Ausführung und lassen die Interrupt Service Routine laufen Auf Systemen mit mehreren CPU-Kernen könnte es auch dazu kommen, dass Threads mit unterschiedlicher Priorität parallel laufen!

13 Scheduling & Prioritäten (3) Um Probleme durch die s.g. Priority Inversion umzugehen, wird unter QNX die Priorität des Clients bei Message Passing zu einem Server- Thread auf diesen vererbt. Der aufgerufene Server-Thread läuft so mit der Priorität des Cliens und wird nicht durch andere Threads an der Ausführung gehindert bzw. hindert keine andere Threads, welche eine niedrigere/höhere Priorität als der Client haben

14 Netzwerk Die Kommunikation über das Netzwerk kann in QNX genau so wie zwischen zwei Prozessen erfolgen - mittels Message Passing Da viele typische Systemaufrufe, wie z. B. der Zugriff auf ein Dateisystem, bereits über Message Passing laufen, sind diese automatisch über das Netzwerk ausführbar Bei open() muss man dafür lediglich als Pfad so was wie /net/nodename/home/username/... angeben Bei manuellem Send-Recive muss man noch vorher die Node-Kennung auflösen lassen

15 Referenzen & Literatur QNX Neutrino RTOS, Getting Started with QNX Neutrino: A Guide for Realtime Programmers, Rob Krten, 2009 An Architectural Overview of QNX, Dan Hildebrand, 1992 QNX Neutrino RTOS, Hassan Assayd, Brendan Grebur, Chin- Jung Liu, Pravesh Ramachandran, 2010 QNX 4 OS, Oliver Gerler, 2000 qnx.com/company/announcements/blackberry_tablet_os.html qnx.com/products/standards.html

16 Fragen?