Seminar: Mobile Geräte 2010/2011 QNX Einführung

Größe: px
Ab Seite anzeigen:

Download "Seminar: Mobile Geräte 2010/2011 QNX Einführung"

Transkript

1 Philipps-Universität Marburg: Alex Maurer, Seminar Mobile Geräte, QNX Einführung 1 Seminar: Mobile Geräte 2010/2011 QNX Einführung Alex Maurer Abstract Diese Seminarausarbeitung gibt einen Überblick über den Aufbau des Echtzeitbetriebssystems (RTOS) QNX. QNX ist ein kommerzielles Betriebssystem, welches vor allem mit dem Fokus auf die embedded-hardware entwickelt wird. Darüber hinaus ist es als Desktopsystem nutzbar und kann auch für den Aufbau von verteilten Systemen eingesetzt werden. Die Echtzeitfunktionalität und die Minimalität können vor allem bei Robotersteuerungen und der Verarbeitung von Echtzeitströmen auf mobilen Geräten nützlich sein. Q I. EINFÜHRUNG NX ist ein skalierbares Echtzeitbetriebssystem, welches auf verschiedenen Architekturen lauffähig ist und sich vor allem für embedded-systeme eignet. QNX zeichnet der sehr schlanke Kernel aus, welcher als Microkernel implementiert ist. Das Betriebssystem ist dafür ausgelegt, mit SMP (symmetric multiprocessing) skalieren zu können und auch in einem Netzwerk verteilt auf mehreren Knoten arbeiten zu können. Der Kernel des Betriebssystems ist sehr schlank gehalten - die meisten Funktionen sind in User-Space-Module ausgelagert. Zwischen den Prozessen bzw. Threads kann auf vielfache Weise kommuniziert werden. In QNX wird von Message Passing exzessiv Gebrauch gemacht. QNX versucht soweit wie möglich POSIX-konform zu sein, definiert aber eine Reihe eigener Erweiterungen um bessere Funktionalität bieten zu können. A. Geschichtliches Ins Leben gerufen wurde QNX von zwei Studenten der University of Waterloo, Dan Dodge und Gorden Bell. Die ersten Versionen gab es damit ab 1980, die ersten Releases ab Damals hieß QNX noch QUNIX bzw. Quantum UNIX und war noch weit von heutigem QNX entfernt. Die Unterstützung des POSIX (Portable Operating System Interface [for Unix]) Standards wurde von QNX seit 1991 verfolgt. Ziel ist es den Entwicklern die Portierung der Software auf QNX zu erleichtern bzw. eine Multiplattform- Entwicklung der Software zu ermöglichen. Zwischendurch gab es sogar offenen Code von QNX bzw. freie Versionen für bestimmte Plattformen für die private Nutzung, doch mittlerweile ist der Code closed und man kriegt eher nur eine 30-tätige Testversion ohne zahlen zu müssen. Natürlich muss das kommerzielle Betriebssystem mit dem kostenfrei verfügbarem Linux konkurrieren. Doch QNX kann einige für sich sprechende Argumente vorzeigen. Das Betriebssystem eignet sich durch schlankeren Aufbau besser für embedded-hardware, es ist leichter erweiterbar, da die Funktionalität in die User-Space-Module ausgelagert wird, man keine Kernel-Module für spezifische Hardware schreiben und integrieren muss und es ist ein RTOS (Real Time Operating System), was ein Linux zuerst ohne weiteres nicht ist. Ein Echtzeitbetriebssystem zu sein bedeutet dabei, dass man damit Systeme bauen kann, die auf Ereignisse innerhalb einer festen Zeitspanne garantiert reagieren können. Auch wenn man eher selten von QNX hört, gibt es dennoch einige Firmen, die dieses Betriebssystem einsetzen. Dazu gehören z. B. viele Vertreter der Autoindustrie, wo QNX vor allem für Multimedia- und Navigationselemente gerne verwendet wird. Sehr oft wird es für Mess-, Kontroll- und Steuersysteme in der Industrie verwendet. Auch die Verwendung bei Robotern bietet sich oft an. Selbst in Atomkraftwerken und Raumschiffen wurde QNX schon eingesetzt. B. Aktuelles Aktuell ist die Version QNX 6.5. Seit Version 4 wird es Neutrino genannt. Es ist für die Plattformen x86, SH-4, PowerPC, MIPS, ARM und andere verfügbar. QNX schmückt sich unter anderem mit folgenden Zertifizierungen: SIL3 (IEC Safety Integrity Level 3) EAL4+ (Common Criteria ISO/IEC Evaluation Assurance Level) POSIX 2003 (POSIX PSE52 Realtime Controller ) Es gibt einen breiten Einsatz von QNX für automotive- Systeme (vor allem Multimediasysteme für PKWs). Weiterhin plant Research In Motion (RIM), der Inhaber von QNX, ein BlackBerry-Tablet mit QNX als Betriebssystem herauszubringen. II. MICROKERNEL QNX verwendet einen Microkernel. Was einen Microkernel ausmacht ist seine geringe Größe und sehr kleiner Aufgabenbereich. Die benötigte, nicht im Microkernel enthaltene Funktionalität, muss mithilfe von Modulen realisiert werden. Braucht man Netzwerkverbindungen, muss ein Netzwerkmodul vorhanden sein und geladen werden, muss man auf die Dateisysteme zugreifen, soll das entsprechende Modul geladen sein usw. Module können auch zur späteren Laufzeit geladen und wieder entladen werden. Zu beachten ist, dass es sich nicht um Kernel-Space-Module

2 2 handelt, wie bei Linux, sondern es lediglich normale Programme sind. Diese Programme haben ihren eigenen Adressraum und können eigene Threads verwalten. Das macht die Entwicklung von solchen Modulen sehr einfach und flexibel. Durch die Auslagerung von vielen Funktionen in die User- Space-Module ist das ganze System stärker gegen die Fehler in den einzelnen Treibern gehärtet. Tritt ein Fehler in einem der Module auf, so ist davon erstmal nur der eine Prozess betroffen und nicht der Kernel selbst. Die einfachere Möglichkeit Treiber und andere ähnliche Module zu schreiben macht die Entwicklung dieser für externe Programmierer einfacher, günstiger und schneller. Der Microkernel von QNX kümmert sich vor allem um das Message Passing, Verarbeitung von Signalen und Thread Scheduling. Andere, für ein Betriebssystem wichtige Funktionen, wie Shared Memory, Process creation & destruction, Pipes, werden durch Module erledigt, die eigentlich vom Kernel entkoppelt sind. III. PROCESS MANAGER Der Process Manager ist ein separater Prozess, welcher für Prozessmanagement, Speichermanagement und Pfadmanagement verantwortlich ist. Nichtdestotrotz ist der Process Manager fest mit dem Kernel gekoppelt und nicht dafür gedacht, vom Benutzer ausgetauscht zu werden. Die Entkoppelung soll dafür dienen, den Kernel selbst sehr klein und schlank zu halten und schnellere Reaktionszeiten dessen zu bieten. Wird ein neuer Prozess gestartet, müssen erstmal einige Verwaltungsaufgaben erledigt werden. Das Format der auszuführenden Datei muss geprüft/entpackt werden, initiales Arbeitsspeichermapping muss angelegt werden, der Code muss in den Arbeitsspeicher geladen werden, es muss festgelegt werden, mit welcher Identifikation der Prozess laufen wird und welche initiale Priorität dieser bekommen soll. Diese Aufgaben werden von dem Process Manager erledigt. Während des Laufs des Prozesses wird der Process Manager seltener gebraucht. Das passiert unter anderem bei Anforderung von Arbeitsspeicher. In diesem Fall muss der Process Manager die Page-Table entsprechend anpassen. Bei Beendigung eines Prozesses muss von diesem belegter Arbeitsspeicher wieder zum freien Speicher hinzugefügt werden. Der Kernel ist darüber zu informieren, dass die evtl. dem Prozess zugeordneten Conditional Vars oder Mutexe von diesem nicht mehr gehalten werden. Bei speziellen Konfigurationen für Hochverfügbarkeitssysteme werden vorher registrierte Alarm-Handles aufgerufen (damit man z. B. einen wichtigen Prozess automatisch neu starten lässt). IV. PROZESSE Programme werden in QNX, wie in allen modernen Betriebssystemen in Prozessen bzw. in Threads ausgeführt. Ein Prozess beinhaltet immer mindestens einen Thread. Hat ein Prozess mehrere Threads, so teilen sich diese den Programmcode und den Speicher. In QNX gibt es eine Vielzahl an Möglichkeiten aus einem Prozess heraus andere Prozesse zu starten: system() exec*() spawn*() fork() vfork() * = es gibt verschiedene Variationen davon Manche der Aufrufe sind QNX-spezifisch und auch wenn diese Vorteile bringen können, werden diese bei der Entwicklung eines Programms, das auch auf anderen Plattformen als QNX laufen soll, eher nicht in Frage kommen. Man muss also teilweise abwägen, mit welchen Methoden man einen neuen Prozess starten möchte. Die einfachste Variante von den genannten ist system(). Es startet eine Shell und erlaubt das Ausführen von bestimmten Kommandos. Exec() transformiert den aktuellen Prozess in einen anderen. Spawn() startet einen neuen Prozess mit dem entsprechendem Programm. Manche der exec*()-varianten sind POSIX-konform, manche sind eine Erweiterung. Alle spawn*() Aufrufe sind nicht POSIX-konform. Fork() dupliziert den Prozess, welcher es aufruft. Vfork() dupliziert auch den Prozess, allerdings nutzt der neue Prozess den selben Adressraum, was dazu führt, dass das vfork() schneller vonstatten geht. Um Probleme zu vermeiden, wird der Elterprozess erstmal angehalten, bis der Kindprozess beendet wird. Vfork() unterstützt auch Systeme mit physikalischem Speicherzugriff, bei denen kein prozessspezifisches Mapping des Adressraumes existiert. Man sollte beachten, dass man aktuell keine multithreaded- Prozesse forken kann, da QNX für solche Fälle keine Behandlung von Mutexen vorsieht und deshalb das Forken einfach abgelehnt wird, solange mehr als ein Thread in dem Prozess gestartet wurde. Für einfache Aufrufe bietet sich somit system() an. Für portierte Programme steht fork() zur Verfügung. Problematisch bei fork() ist, dass die Dateihandler für offene Dateien erstmal mitkopiert werden. Deshalb wird für QNX-only Programme empfohlen entweder vfork() zu nutzen, was zur Folge hat, dass der Elternprozess erstmal blockiert wird, oder spawn(), welches erlaubt die beiden Prozesse, den Elternprozess als auch den Kindprozess parallel laufen zu lassen. V. THREADS Eine viel elegantere und vor allem ressourcensparendere Methode aus einem Prozess heraus parallel laufende Berechnungen anzustoßen ist die Verwendung von Threads

3 3 unterhalb des Prozesses. Die Vorteile von Threads liegen nicht nur darin, dass man diese deutlich schneller gestartet bekommt und auch nicht darin, dass diese weniger Speicherressourcen verbrauchen. Threads erlauben vor allem Serveranwendungen zu schreiben, welche bei fehlenden Anfragen blockiert schlafen ohne CPU- Ressourcen zu verschwenden und andererseits mehrere sich zeitlich überschneidende Client-Anfragen entgegennehmen können und auch parallel verarbeiten können. Würde ein Server als single-thread laufen und würde Client1 eine Anfrage an diesen geschickt haben, müsste ein Client2 warten, bis Server die Anfrage von dem Client1 abgearbeitet hat oder zumindest die Anfrage entgegengenommen und in eine Warteschlange gestellt bzw. weitergereicht hat. Das Warten könnte heißen, dass der Kernel die Zustellung der Anfrage ganz verweigert und der Client2 diese in einer Loop-Schleife immer wieder auszuführen versucht, oder dass der Kernel für den Server eine Anfragewarteschlange verwaltet, welche einerseits Speicherplatz verbrauchen würde und bei der andererseits der Kernel keine Information darüber hat ob der Server jemals wieder empfangsbereit sein wird. Auf SMP-Systemen sind Threads eine schöne Möglichkeit seine Berechnungen parallel auf mehreren CPUs laufen zu lassen und die Ergebnisse über gemeinsamen Speicher verwalten zu lassen. Aufteilbare Probleme kann man zur Laufzeit auf n Threads aufteilen, wobei die Variable n zur Laufzeit abhängig von der Anzahl der vorhandenen bzw. unausgelasteten CPUs gewählt wird. Natürlich lässt es sich auch mit mehreren Prozessen lösen, aber da muss man die Daten des Problems erstmal unter den Prozessen verteilen. Und selbst bei der Nutzung von Shared Memory kann der Aufwand für das Starten neuer Prozesse erheblich sein. Um einen neuen Thred zu starten, muss man in irgendeinem bestehenden einfach pthread_create() mit passenden Parametern aufrufen. Das heißt vor allem, dass die neu aufgerufenen Threads wieder Threads starten können usw. Zu den Parametern gehört eine Variable, in der die Thread-ID gespeichert wird, eine Sammlung von Attributen für den Thread-Start, die Routine, mit welcher der Thread gestartet werden soll (das ist ein weiterer Unterschied zu fork(), wo immer die main() aufgerufen wird) und Argumente für diese Routine. Zu den Thread-Attributen zählen unter anderem Flags (z. B. für detached bzw. joinable ), Stackgröße, Stackadresse und guardsize, bei Exit des Threads aufzurufende Funktion, Schedulingparameter und noch paar weitere. Guardsize ist ein virtueller Schutzbereich hinter dem Stack, welcher nicht beschrieben werden darf. Es soll dazu dienen, einige der Bufferoverflows zu verhindern und wird heute von vielen Betriebssystemen verwendet. Eine recht interessante Sache in QNX ist, dass man einem Thread (auch einem Prozess) neben der Priorität die Scheduling-policy vorgeben kann. Threads starten mag jetzt kompliziert klingen, aber man kann alle Parameter bis auf die Routine auf NULL setzen, wenn man sich darüber keine Gedanken machen will und keine Gedanken machen muss. Nun, der eine Vorteil von Threads ist, dass diese parallel die Berechnungen durchführen können. Hat man ein größeres Problem aufgeteilt, will man ab dem Zeitpunkt, an dem alle Teilberechnungen fertig sind, die Ergebnisse wieder zusammenführen und z. B. ausgeben. Das heißt, man will in einem Manager -Thread mitbekommen, wenn die Arbeiter -Threads fertig geworden sind, ohne aktiv überprüfen zu müssen. Für diese Aufgabe dienen einerseits ein bereits genanntes Thread-Joining und andererseits die Barrieren. Mit pthread_join(tid, NULL) wartet man in dem nun geblockten Thread darauf, dass der Thread mit der Thread-ID TID beendet wird. Die Strategie wäre dann, n Arbeiter-Threads zu starten und danach in einer Schleife jedes TID zu joinen. Selbst wenn die Threads in einer anderen Reihenfolge beendet werden gibt es bei dieser Strategie keine Probleme. Die andere Möglichkeit ist mit den Thread-Barrieren gegeben. Ziel ist nach wie vor ein passives Warten. Nur diesmal wartet man darauf, dass eine festgelegte Anzahl von Threads einen bestimmten Punkt erreicht hat. Ein Beispiel wäre eine Anwendung, welche 10 Threads Werte ausrechnen lässt, aber bereits nach 5 vorliegenden Ergebnissen diese ausgeben will. Barrieren werden auf folgende Weise benutzt: Es wird global eine Barriere definiert und mithilfe von pthread_barrier_init() initialisiert, wobei man vor allem die Anzahl von fertigen Threads vorgibt, die ausreichen um den Manager-Thread wieder in den READY-Status zu versetzen. Dann setzt sich das Manager-Thread erstmal selbst mit Hilfe von pthread_barrier_wait() in den BLOCKED Zustand. An bestimmten Stellen (z. B. fast am Ende des Codes) rufen die Threads dann pthread_barrier_wait() auf und werden erstmal in den Zustand BLOCKED versetzt. Haben genügend Threads den Aufruf gemacht, wachen der Manager-Thread sowie alle bisher geblockten Threads auf. Diejenigen Threads, welche noch nicht soweit waren die wait-methode aufzurufen, werden bei dem entsprechendem Aufruf nicht mehr blockiert. Alle Threads laufen, im Unterschied zu Joining, noch weiter durch und beenden sich im Allgemeinem erst irgendwann später. Hat man seine Anwendung mit Hilfe von Threads programmiert ist es schon die halbe Miete für die parallele Ausführung auf SMP-Systemen. Nur muss man dafür einige Punkte beachten. Auf einem SMP-System können die Threads wirklich parallel laufen - man darf sich nicht auf FIFO- oder prioritätsbasiertes Scheduling verlassen. Threads und Interrupt Service Routines (ISRs) können parallel laufen und sich gegenseitig in die Quere kommen. Operationen, von denen man glaubt, sie seien atomar, können können auf bestimmten Plattformen nicht atomar sein. QNX bietet in Verbindung mit Threads spezielle Funktionalität an, welche das Erzeugen und Verwalten von vielen gleichen Threads in einem Prozess vereinfacht. Es lassen sich sogenannte Thread-Pools erstellen. Die Funktion

4 4 thread_pool_create() bekommt unter anderem folgende Parameter: Funktionhandler selbst, lo_water, increment, hi_water, maximum. Thread Pool (aus [1]) Es wird nach dem start des Pools automatisch darauf geachtet, dass mindestens lo_water Threads in dem Zustand BLOCKED warten. Sinkt die Anzahl unter lo_water, so werden incremet viele (oft wird man increment = 1 nehmen) wartende Threads erstellt. Die Idee ist, dass Threads in dem Pool eine Endlosschleife Recieve() -> Compute() -> Answer() -> Recieve() durchlaufen, wobei Recieve() den blockenden Zustand hervorruft, in dem ein Thread auf Anfragen wartet. Kommt ein Thread wieder in den blockierten Zustand, so wird er der Liste von bereitgestellten Threads wieder hinzugefügt. Sollte die Liste bereits mehr als hi_water wartende Threads enthalten, wird der Thread entsorgt. Damit bewegt sich der Pool wartender Threads immer in dem Bereich zwischen lo_water und hi_water. Ein Webserver kann z. B. gleichzeitig mit x Threads auf Anfragen von Clients warten um mehrere Anfragen parallel entgegennehmen zu können ohne die Clients zu blockieren (mehrere Threads können sich als Empfänger von Channel- Nachrichten registrieren und es wird ein beliebiger Thread dafür genommen, der sich im BLOCKED Status befindet, wenn eine neue Anfrage über den bestimmten Channel reinkommt). Zusätzlich wird sichergestellt, dass in dem Pool maximal maximum Threads existieren, wobei dazu sowohl laufende als auch blockierte Threads zählen. A. Synchronisierung 1) Mutexe Mutexe bieten die einfachste Möglichkeit, in einem Multithreading-Prozess globale Variablen exklusiv zu nutzen. Das Prinzip ist einfach - man versucht einen Lock mit bestimmter Kennung zu bekommen. Ist der Mutexes von einem anderen Thread gesperrt, wartet man passiv so lange, bis man eine exklusive Sperrung bekommen kann. Ab dann ist man der Inhaber des Mutex und kein anderer kann es bekommen, solange man es nicht entsperrt. Für die logische Verbindung zwischen Variablen und Mutexen sowie für die richtige Anwendung in dem Code ist der Programmierer selber verantwortlich. Für Mutexe stehen folgende Funktionen bereit: pthread_mutex_lock (&mutex); phtread_mutex_unlock (&mutex); Mutex bei Threads benutzen, die in verschiedenen Prozessen laufen. Die Vergabe von frei gewordenen Mutexen findet in QNX prioritätsbasiert und bei gleicher Priorität abhängig von der Wartezeit statt. 2) Semaphore QNX bietet ebenfalls Semaphores an, welche eine Verallgemeinerung von Mutexen darstellen. Im Gegensatz zu einem Mutex können hier bis zu n Inhaber einen Lock bekommen, wobei n im Vorfeld festgelegt wird. 3) Readers/writer locks Will man unter verschiedenen Threads auf globale/gemeinsame Variablen zugreifen, kann es zu einem Problem führen. Einerseits muss man dafür sorgen, dass maximal ein Thread schreibend zur bestimmten Zeit darauf zugreifen darf und andererseits muss sichergestellt werden, dass kein Thread schreibend darauf zugreift, wenn andere Threads lesend darauf zugreifen. Um dies zu bewerkstelligen werden spezielle Funktionen bereitgestellt. Zuerst muss man ein pthread_rwlock_t Objekt erzeugen und dann mit diesem versuchen den speziellen Lock zu bekommen in dem man pthread_rwlock_*() Funktionen aufruft. Es gibt zwei Typen: Rdlock und wrlock blockieren den Thread, bis andere Threads ihre Locks soweit zurückgezogen haben, dass der entsprechende Lock möglich wird. Tryrdlock und trywrlock blockieren nicht, sondern liefern im Problemfall entsprechende Statusinformation. Hat man den Lock, sollte man die beabsichtigte Operation durchführen und dann mit pthread_rwlock_unlock() die Sperre wieder entfernen. Reader/Writer Locks schützen also in Wirklichkeit noch nicht davor mit verteilten Variablen Unsinn anzustellen - die bieten lediglich ein Werkzeug für den Programmierer die Nutzung solcher Variablen zwischen den parallel laufenden Threads zu synchronisieren. 4) Sleepon Locks Oft will man in einem Thread die Änderung einer Variablen durch den anderen Thread mitbekommen. Ein ganz schlechter Ansatz wäre ein aktives Polling wie z. B. while(gvar == 0). Viel besser wäre es zu blockieren und den anderen Thread einen erst dann aufwecken zu lassen, wenn dieser die gvar auf z. B. 1 gesetzt hat. Dabei bleibt noch die Problematik, dass man nicht gleichzeitig schreibend und lesend von mehreren Threads auf die gvar zugreifen sollte. All dies ist mit Hilfe von pthread_sleepon_*() Funktionen möglich. In dem zu wartendem Thread konstruiert man folgendes Konstrukt: Besteht zwischen zwei Prozessen unter QNX Shared Memory, so kann man ein in dem shared Bereich definiertes

5 5 pthread_sleepon_lock(); while(gvar == 0) { pthread_sleepon_wait(cookie); // passives Warten } work(); // braucht Information über gvar == 0, dass es laufen kann gvar = 5; pthread_sleepon_unlock(); Dabei passiert folgendes: Zuerst wird über die sleepon ein Mutex gesetzt (und evtl. gewartet, bis es möglich wird), dann die Variable ausgelesen und wenn der Wert noch nicht geändert wurde, wird die wait() Funktion aufgerufen, welche den Thread erstmal blockiert (passives Warten). In dem anderen Thread will man aber gvar ändern können. Also macht die wait() noch mehr: Erst Lock entfernen, dann blockieren, dann wieder den sleepon-lock setzen. In dem anderen Thread würde es folgendermaßen ablaufen: getthingsdone(); pthread_sleepon_lock(); gvar == 0; pthread_sleepon_signal (cookie); pthread_sleepon_unlock(); Die vielen sleepon_lock und _unlock verwirren ein bisschen. Die werden auch tatsächlich ohne Parameter aufgerufen - das könnte andere Threads zusätzlich blockieren. Im Prinzip ändert der andere Thread die gvar-variable und lässt den wartenden Thread aufwecken. Beim Aufwecken wird der dritte Teil der wait() Funktion noch abgearbeitet, in dem ein Lock gesetzt wird - es muss evtl. noch gewartet werden, bis der zweite Thread dieses unlockt. Evtl. sollte bei diesem Konzept die Möglichkeit geschaffen werden, mehrere Mutexe über IDs für die Locks nutzen zu können. Es sollte auch beachtet werden, dass trotz dem, dass signal() den entsprechenden Thread aufweckt, man die eigentliche Variable gvar tatsächlich in der While-Schleife prüfen sollte denn QNX sieht es vor, dass wartende Prozesse in seltenen Fällen spontan aufgeweckt werden könnten. 5) Bedingte Variablen Neben _sleepon() gibt es auch noch pthread_cond_*() Funktionen welche mit Conditional Vars und Mutexen agieren. Diese können viel flexibler als die eingeschränkten sleepon-funktionen eingesetzt werden. Ansonsten haben diese die gleiche Aufgabe. Die beiden Ansätze erlauben auch das Aufwecken von mehreren Threads indem die entsprechenden _broadcast() Funktionen aufgerufen werden. Gibt es mehrere wartende Threads und wird ein _signal() aufgerufen, wird ein beliebiger Thread aus der Menge wartender Threads mit höchster Priorität aufgeweckt. VI. SCHEDULING In QNX gilt gründsätzlich folgendes Prinzip: Ein Thread (oder Prozess) mit einer höheren Priorität wird immer Vorrang vor einem Thread mit niedrigerer Priorität haben (Preemption) und entsprechend so lange ausgeführt, so lange es nötig ist. Das hilft niedrige Reaktionszeiten für wichtige Prozesse zu garantieren und wird bei non-rtoss eher andes gehandhabt. Es funktioniert natürlich nur solange gut, solange die Threads mit hoher Priorität nur relativ kurz aktiv werden und dann wieder in den blockierten Zustand wechseln. Gibt es in der Process Queue zwei Threads mit gleicher Priorität muss weiterhin mit einem Scheduling-Algorithmus entschieden werden, welcher die CPU als nächstes benutzen darf. Zu diesem Zweck gibt es unter QNX im Wesentlichen zwei Algorithmen: Round-Robin (RR) Scheduler und First-In, First-Out (FIFO). A. RR Round-Robin ist dem Scheduler von nicht-echtzeit Betriebssystemen sehr ähnlich. Ein ausgewählter Thread wird erstmal für eine festgelegte Zeit (timeslice) laufen gelassen (typisch 4 ms) und beim Ablauf der Zeit prüft der Kernel, ob noch andere gleich priorisierte Threads im READY-Status sind. Findet der Kernel welche, so wählt er einen anderen Thread, der als nächstes für die festgelegte Zeit die CPU nutzen darf. B. FIFO Der FIFO-Scheduler ist dagegen eher ungewöhnlich. Ein Thread kann solange laufen, bis er entweder in den Zustand BLOCKED wechselt oder von einem Thread mit noch höherer Priorität preempted wird. Threads mit gleicher Priorität müssen einfach unbestimmte Zeit warten. Andere Threads können dann zur Ausführung kommen, wenn der vorher gelaufende Thread blockierende Operationen ausführt, z. B. bei Semaphore-Operationen. Um FIFO effektiver nutzen zu können gibt es einen Kernel- Call namens sched_yield(). Dieser kann aus einem laufenden Thread aufgerufen werden und erlaubt dem Scheduler, einen anderen Thread auszuführen, so lange der die gleiche Priorität hat und keine niedrigere (Threads mit einer höheren Priorität werden immer Vorrang bekommen). Mit dem Aufruf sched_yield() können also Threads, die mit einer gleich hohen Priorität laufen, bei einem entsprechenden Programmdesign sich gegenseitig immer die CPU-Zeit zugeben. VII. PRIORITÄTEN UND VERERBUNG Das Wichtigste zu den Prioritäten wurde schon im vorhergehendem Abschnitt beschrieben. Die Aufgabe von QNX, ein Echtzeitbetriebssystem zu sein und die strikte Behandlung von Thread-Prioritäten machen eine Prioritätsvererbung nötig. A. Priority Inversion Priority Inversion ist ein Phänomen, dass die Aufgaben eines low-priority Threads privelegierter abgearbeitet werden als die Aufgaben eines high-priority Threads. Es würde passieren, wenn ein low-priority Thread eine Berechnungsanfrage bei einem Server-Thread mit ganz hoher Priorität stellt, während der high-priority Thread für kurze Zeit blockiert war. Der Server-Thread hat eine höhere Priorität

6 6 als der high-priority Thread und wird deshalb auch dann noch laufen, wenn der high-priority Thread wieder READY wird. Dabei erledigt der Server aber eine Anfrage von einem unwichtigen low-priority Thread. Um zu verhindern, dass ein low-priority Thread die Ausführung von einem high-priority Thread auf diese Weise blockieren kann, wird am Server die geringere Priorität des anfragenden Threads vererbt - der Server-Thread wird nun mit der gleichniedrigen Priorität die Anfrage ausführen wie der anfragende Thread. Es gibt auch das inverse Problem, dass ein high-priority Thread eine Anfrage an einen niedrigerpriorisierten Server- Thread schickt und blockiert wird, nicht entblockt werden kann, weil andere Threads mit mittleren Prioritäten den Server-Thread davon abhalten zu laufen. Dem begegnet man mit der Erhöhung der Priorität des Server-Threads auf die des anfragenden Threads. Die Priority Inheritance ist standardmäßig immer aktiv, wenn Message Passing über die Channels benutzt wird. Optional kann man diese auch ausschalten. Ein kleines Problem bleibt noch - bleibt der Server-Thread nach dem Beantworten einer Anfrage weiter laufen, läuft dieser mit einer falschen Priorität. Er kann von sich selbst aus durch einen Kernel-Call die Priorität zurücksetzen lassen - dazu gezwungen wird er jedoch nicht. VIII.MESSAGE PASSING Ein großes Fundament, auf dem QNX aufbaut ist die Kommunikation zwischen den Prozessen/Threads mittels Message Passing. Um einen Server dazu zu bewegen, etwas zu berechnen, muss man ihm einfach eine passende Nachricht schicken und auf die Antwort warten. Typischwerweise registriert der Server einen Channel und wartet blockiert darauf, dass er über diesen eine Nachricht bekommt. Der Client ruft irgendwann Send() auf. Falls der Server gerade die Nachricht nicht annehmen kann, ist der Client im send-blocked-zustand. Hat der Server die Anfrage angenommen (wahrscheinlicher), ist der Client im recieveblocked-zustand - für den Client eigentlich das Gleiche - er bleibt blockiert, bis der Server (z. B. nach einer Berechnung) die Antwort mit Reply() zurückschickt. Danach könnte der Server wieder mittels Recieve() in einen wartenden blockierten Zustand wechseln. Durch diese Vorgehensweise wird ein aktives Warten um jeden Preis vermieden. Interessanten Ansatz bietet die Subserver-Architektur. Der Server bekommt von Subservern jeweils ein Send(), antwortet aber erstmal nicht auf diese. Subserver können entweder Threads sein oder andere Prozesse - es sind die Mitarbeiter des Servers. Diese bleiben zunächst blockiert und verbrauchen keine weitere Ressourcen. Der Server selbst wartet mit Recieve() darauf, dass jemand ihm Aufgaben zustellt. Wenn er diese bekommt, leitet er diese an ausgewählte Threads weiter, die jetzt aktiv werden. Der Server bleibt damit während der Berechnung weiterhin verfügbar. Sind die Arbeiter-Threads fertig, schicken diese mittels Send() die Ergebnisse an den Server und werden damit wieder recieve-blocked. Um Message Passing nutzen zu können, muss der Server mittels ChannelCreate() einen Channel registrieren, der Client mittels ConnectAttach() eine Verbindung zu dem {Node, PID, Channel} herstellen und mittels MsgSend() eine Nachricht an den Server schicken, welcher mittels MsgRecieve() darauf wartet. Als Parameter übergibt man unter anderem einen Sendepuffer mit einer Größenangabe und einen Empfangspuffer ebenfalls mit einer Größenangabe. Auf der Serverseite passiert das Selbe. Die Nachricht wird von einem beliebigen blockierten Thread empfangen, welcher mit MsgRecieve() auf dem ensprechendem Channel wartet. Der Kernel beschneidet die zu übertragenden Nachrichten automatisch, wenn diese in einen der angegebenen Puffer nicht passen, um auf keinen Fall Pufferüberläufe zu verursachen. Man muss also selbst darauf aufpassen, dass die Puffergrößen bzw. Nachrichtengrößen in ihrer Größe passen. Um auch größere Mengen übertragen zu können, gibt es MsgRead() und MsgWrite() Methoden. Eine andere Möglichkeit besteht in Benutzung von Multipart-Messages, welche nach und nach vom Kernel kopiert werden. Ein Problem des blockierenden Message Passing ist, dass zwei Threads einander Nachrichten zuschicken könnten und so in den Deadlock geraten, weil sie für immer blockiert bleiben. Darum muss man während der Planung des Systems eine Sendehierarchie definieren, innerhalb derer die Nachrichten nur in eine Richtung und die Antworten dann in die andere Richtung versandt werden dürfen.

7 7 Alternativ muss man nicht-blockierendes Message Passing benutzen - sogenannte Pulses. Pulses sind kleine Nachrichten (auf 40 bits beschränkt), welche den Sender nicht blockieren und welche in eine Warteschlange eingereiht werden, wenn der Server aktuell kein Recieve() ausführt. Pulses sind keine Send-Recieve Nachrichten, sondern gehen nur bis zum Empfänger und erledigen die Sache damit vollständig. Die Pulses werden sowohl von normalen MsgRecieve() Funktionsaufrufen als auch von speziellen MsgRecievePulse() empfangen. Letztere dienen dazu nur die Pulses zu empfangen. Damit kann man sozusagen auf zwei Ebenen Nachrichten austauschen und damit bestimmte Strategien einsetzen, um die Reihenfolge der Ausführung zu planen. Daneben gibt es noch MsgDeliverEvent() Funktion, die bei einer Anfrage an den Server erlaubt, sofort eine Nachricht zu bekommen, welche den Client wieder READY macht und später vom Server ein Send() zu bekommen, welches das Ergebnis übermittelt. Durch spezielle Struktur ist damit die Umgehung der Sendehierarchie möglich. Das Universelle an Message Passing ist, dass man es transparent für Nachrichten zwischen Threads, welche auf unterschiedlichen Nodes in einem Netzwerk laufen, benutzen kann. Man muss nur neben ProzessID und ChannelID auch noch eine NodeID angeben - Qnet erledigt alles andere automatisch, inkl. Behandlung von temporären Netzwerkfehlern. Nachteile sind nur die höheren Verzögerungen, keine Verlässlichkeit bei MsgDeliverEvent(), im Gegensatz zu lokalem Anwenden blockierende MsgReply(), MsgRead() und MsgWrite(). NodeID kann man über Qnet und eine eindeutige Kennung eines Rechners auflösen lassen. In dem Ressource Manager werden die Netzwerknodes unter /net/kennung abgebildet. Bei Vergabe von den Kennungen muss man eben aufpassen, keine gleichen zu vergeben. Außerdem wird bei Qnet immer von einem vertrauenswürdigem Netzwerk ausgegangen. Man kann viele Ressourcen auch über das Netzwerk nutzen - z. B. entfernt liegende Dateisysteme. Die Aufrufe werden automatisch in passende Send-Befehle transformiert und die NodeIDs werden ensprechend aufgelöst. Das Öffnen der Datei auf einem entfernten System sieht dann genau so aus wie das Öffnen auf einem lokalen System: fd = open ("/net/kennung/etc/passwd", O_WRONLY); IX. INTERRUPTS Neben Scheduling muss ein Betriebssystem auch die Interrupts behandeln, welche von der Hardware generiert werden. Normalerweise unterbricht ein ankommender Interrupt immer sofort die Ausführung des aktuellen Threads durch die CPU und es wird an die CPU die numerische Kennung des Interrupts gemeldet. Das heißt vor allem, dass man selbst bei der Wahl von FIFO-Scheduling und einer sehr hohen Priorität die Unterbrechung seines Threads gar nicht verhindern kann und damit rechnen muss, dass auch bestimmte Routinen dazwischen ausgeführt werden. Um spezielle atomare Funktionen durchzuführen, werden für kurze Zeit die Interrupts abgeschaltet und dann wieder eingeschaltet. Die Behandlung der Interrupts übergibt der Kernel an die Interrupt Service Routine (ISR). Da diese bei jedem Interrupt aktiv wird, ist es vor allem bei einem RTOS sehr wichtig, dass die Behandlung in sehr kurzer Zeit erfolgt und wenigstens die Interruptquelle erstmal zufriedengestellt wird, sodass nicht unmittelbar im Anschluss an die ISR der selbe Interrupt gleich wieder aufgerufen wird. Die mögliche Behandlung des Grundes für den Interrupt kann dann an einen Thread delegiert werden. Beispielweise könnte der Festplattencontroller melden, er habe die angefragten Daten in einem DMA-Bereich abgelegt, die ISR löscht die entsprechenden Flags in dem Controller und sendet eine Nachricht an den Filesystem-Prozess. Danach wird die ISR beendet und der Kernel bekommt mit, dass der Interrupt nun behandelt wurde. Irgendwann später wird dann der Filesystem-Prozess aufgeweckt und erledigt alles weitere, wie z. B. lange dauerndes Daten-Kopieren. In QNX gibt es zwei Arten, eine ISR anzumelden. Dies wird mit Hilfe von zwei Funktionen gemacht, welche aus einem Prozess aufgerufen werden können. Natürlich muss der Prozess dazu erforderliche Rechte besitzen. InterruptAttach() definiert eine ISR, welche vom Kernel bei der bestimmten Interruptkennung aufgerufen wird. Die ISR wird dann sofort ausgeführt und erlaubt eine schnelle Vorverarbeitung des Ereignisses. Der Nachteil ist, dass die ISR sehr eingeschränkte Funktionsmenge und des Speichers zur Verfügung stehen. InterruptAttachEvent() dagegen übermittelt dem Kernel Informationen, welcher Thread beim Auftretten eines Interrupts dessen Behandlung übernehmen wird (die entsprechende Interruptkennung wird solange maskiert) und folglich von dem Kernel aufgerufen werden soll. Generell wird es länger dauern, bis mit der Verarbeitung des Interrupts begonnen wird. Auf der anderen Seite könnte es vorteilhaft für Ereignisse sein, welche sowieso erst eine aufwändige Behandlung erfordern, bevor die Interruptquelle deaktiviert werden kann. Außerdem wird das Schreiben und Debuggen von solchen Interrupthandlern einfacher. Weiterhin gibt es weniger Kollateralschaden, wenn der Interrupthandler mal abstürzen sollte, da dieser hier nicht im Kernel-Space läuft. X.TIMER Um in einem Programm bestimmte Zeitperioden zu überspringen ohne aktiv warten zu müssen, stellen die Betriebssysteme Timer zur Verfügung. Ziel ist es, den Thread zu blockieren und zu einem zuvor festgelegtem Zeitpunkt von dem Betriebssystem aufwecken zu lassen. Damit das Betriebssystem die aktuelle Zeit kennt und damit der Kernel die Gelegenheit hat, regelmäßig zu prüfen, ob bereits ein Thread aufgeweckt werden muss, gibt es regelmäßige Interrupts von einer Hardwareuhr. Diese finden z. B. alle 10 ms statt. QNX erlaubt auch feinere Zeitauflösung beim Warten.

8 8 Dabei wird der Rest, der dann z. B. kleiner als 10 ms ist, durch aktives Warten überbrückt bzw. die aktuelle Zeit wird anhand des abfragbaren Taktcounters der CPU ermittelt. Beim Anlegen eines Timers hat man die Möglichkeit, die Dauer des Schlafens anzugeben (man gibt die Dauer an, Kernel merkt sich AktuelleZeit() + Dauer) oder eine absolute Zeit (Werte in ms von 1970 bis Jetzt() gelten als relative Werte). Der Kernel verwaltet eine sortierte Liste von Timern, so dass er bei einem Clock-Interrupt nur einmal den top- Eintrag in der Liste mit der aktuellen Uhrzeit vergleichen muss. Liegt der top-eintrag weiterhin in der Zukunft, liegen alle anderen Timer Einträge ebenfalls noch in der Zukunft. Nicht immer will man einen blockierenden Timer aufrufen - manchmal will man einen nicht-blockierenden Timer haben. Das ist ebenfalls möglich. Zu den Benachrichtigungsmöglichkeiten zählen in diesem Fall: einen Pulse senden ein SIGNAL senden einen neuen Thread erstellen. Nicht-blockierende Timer können auch als periodisch angemeldet werden. Zudem hat man die Möglichkeit festzulegen, welche Zeitbasis durch den Timer benutzt werden soll. Aktuell gibt es drei Zeitbasen in QNX: Realtime (basiert auf den Zählungen der RTC) Softtime (zählt nur, solange die CPU aktiv läuft) Monotonic (sichert zu, immer nur monoton steigend zu sein; die Werte haben dagegen eher keinen Bezug zu der realen Zeit) XI. NETZWERK Wie bereits erwähnt, besitzt QNX eine Netzwerkkomponente namens Qnet, welche einfache Handhabung von verteilten Lösungen unterstützt. Qnet erweitert viele in QNX benutzte Funktionen um die Fähigkeit über das Netzwerk zu agieren. Unter anderem kann man leicht die entfernten Dateisysteme ansprechen, verteilte Anwendungen ausführen lassen, das Message Passing über das Netzwerk zu den Threads, welche auf anderen Rechner laufen, zustellen und die NodeIDs von den teilnehmenden Maschinen aufzulösen. Solange man Funktionen von höherem Level einsetzt, wie Beispielweise Open() von einem Dateisystem, muss man nichtmal irgendwas Netzwerkspezifisches angeben. Das einzige Sichtbare ist dann der Pfad zu der Datei, der mit /net beginnt. Was jedoch nicht über das Neztwerk geht ist anlegen von Shared Memory zwischen zwei Prozessen. Man muss also bei verteilten Anwendungen immer zu Message Passing greifen. XII. RESSOURCE MANAGER Der Ressource Manager ist dafür verantwortlich, dass verschiedene Prozesse sich als Ressourcentreiber registrieren können und unter einem Pfad in dem Namensraum zugänglich gemacht werden. Um also einen Dateisystemtreiber für QNX zu schreiben, muss man nicht den Kernel erweitern, es reicht ein normales Programm zu schreiben, welches eine vordefinierte Menge an Funktionen zur Verfügung stellt (vor allem io_open(), io_read(), io_write()). Die Ressourcen werden dann unter einem bestimmten Pfad eingebunden, z. B. /dev/ser1 für seriellen Port usw. Man kann auch die Ressourcen von einem entfernten System erreichen, z. B. Zugriff auf Dateien von dem Knoten mit der Kennung fileserver : /net/fileserver/home/user/filename.txt. XIII.FAZIT QNX ist ein Echtzeitbetriebssystem, welches die Möglichkeiten bietet ein System zu erstellen, das eine enorme Flexibilität bietet und gleichzeitig sehr schnelle Reaktionszeiten ermöglicht. Es ist sowohl POSIX-konform, was einfachere Portierung wie auch schnelleres Anlernen der Programmierung für QNX ermöglicht, als auch auch mit einigen Erweiterungen versehen, die das Ziel von QNX, flexibel und schnell zu sein, unterstützen. In der aktuellen Version ist QNX gleichermaßen dafür ausgelegt, auf einem sehr kleinem embedded-system als auch auf einem Desktopsystem als auch auf einem über mehrere hunderte Nodes verteilten System zu laufen. SMP ist ebenfalls problemlos möglich. Es ist viel dafür gemacht worden, ein schnell reagierendes und ausfallsicheres System mit QNX bauen zu können. Das Betriebssystem ist dennoch stärker dafür ausgelegt, dass man damit industrielle bzw. embedded- Systeme baut. So setzt man bei manchen Konzepten darauf, dass das Netzwerk bzw. die Anwendungen vertrauenswürdig sind. In einem End-User kontrollierten System darf man eher nicht davon ausgehen. Natürlich hat QNX vor allem durch Linux starke Konkurrenz, aber es gibt viele Bereiche, in denen sich QNX dank Verlässlichkeit und niedriger Reaktionszeit durchgesetzt hat. REFERENZEN [1] QNX Neutrino RTOS, Getting Started with QNX Neutrino: A Guide for Realtime Programmers, Rob Krten, 2009 [2] An Architectural Overview of QNX, Dan Hildebrand, 1992 [3] QNX Neutrino RTOS, Hassan Assayd, Brendan Grebur, Chin-Jung Liu, Pravesh Ramachandran, 2010 [4] QNX 4 OS, Oliver Gerler, 2000 [5] l (Datum: ) [6] (Datum: ) Alex Maurer Student der Philipps-Universität Marburg

Seminar: Mobile Geräte QNX Einführung

Seminar: Mobile Geräte QNX Einführung Seminar: Mobile Geräte QNX Einführung Vortragender: Alex Maurer 2010/2011 Philipps Universität Marburg Echtzeitbetriebssystem QNX QNX ist ein RTOS (Real Time OS) vorhersagbares Zeitverhalten niedrige Latenz

Mehr

RTEMS- Echtzeitbetriebssystem

RTEMS- Echtzeitbetriebssystem RTEMS- Echtzeitbetriebssystem Name: Hussein Hammoud Matrikel- Nr.: 230768 Studiengang: Technische Informatik Fach: Projekt Eingebettete Kommunikation Technische Universität Berlin Sommersemester 2006 RTEMS-

Mehr

Operating System Kernels

Operating System Kernels Operating System Kernels von Patrick Bitterling 1 Themenübersicht -Eine Einleitung über Kernel -Begriffserklärung, Architekturen -Kernel Subsysteme -Prozess-Scheduling, Speichermanagement,... -Der Networking

Mehr

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis...

A Kompilieren des Kernels... 247. B Lineare Listen in Linux... 251. C Glossar... 257. Interessante WWW-Adressen... 277. Literaturverzeichnis... 1 Einführung................................................ 1 1.1 Was ist ein Betriebssystem?............................... 1 1.1.1 Betriebssystemkern................................ 2 1.1.2 Systemmodule....................................

Mehr

Betriebssystembau (BSB)

Betriebssystembau (BSB) Betriebssystembau (BSB) 6. Übung http://ess.cs.tu-.de/de/teaching/ws2013/bsb/ Olaf Spinczyk olaf.spinczyk@tu-.de http://ess.cs.tu-.de/~os AG Eingebettete System Informatik 12, TU Dortmund Agenda Vorstellung

Mehr

Domänenmodell: Fadenkommunikation und -synchronisation

Domänenmodell: Fadenkommunikation und -synchronisation Domänenmodell: Fadenkommunikation und -synchronisation Alexander Humphreys, Reinhard Rösch, Fabian Scheler 15. Mai 2003 Inhaltsverzeichnis 1 Domänendefinition 1 2 Domänenlexikon 1 3 Konzeptmodelle 4 4

Mehr

Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition)

Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition) Ein Prozess kann unmittelbar vom Zustand 1. Running in den Zustand Ready 2. Running in den Zustand Blocked 3. Ready in den Zustand Running Klausurvorbereitung VS1 (Prof. Brecht) (B0rg Edition) Der Adressraum

Mehr

Der Scheduler von Windows Konzepte und Strategien

Der Scheduler von Windows Konzepte und Strategien Gliederung Der Scheduler von Windows Konzepte und Strategien Daniel Lohmann 1 Grundbegriffe 2 Eigenschaften des Schedulers Grundlegende Eigenschaften Prioritätenmodell Dynamische Prioritätenanpassungen

Mehr

Technische Informatik II

Technische Informatik II Institut für Technische Informatik und Kommunikationsnetze Technische Informatik II Übung 1: Prozesse und Threads Aufgabe 1: Prozesse und Threads a) Wie verhält sich eine Applikation die aus mehreren Prozessen

Mehr

Architektur Verteilter Systeme Teil 2: Prozesse und Threads

Architektur Verteilter Systeme Teil 2: Prozesse und Threads Architektur Verteilter Systeme Teil 2: Prozesse und Threads 21.10.15 1 Übersicht Prozess Thread Scheduler Time Sharing 2 Begriff Prozess und Thread I Prozess = Sequentiell ablaufendes Programm Thread =

Mehr

Rechnernutzung in der Physik. Betriebssysteme

Rechnernutzung in der Physik. Betriebssysteme Rechnernutzung in der Physik Betriebssysteme 1 Betriebssysteme Anwendungsprogramme Betriebssystem Treiber BIOS Direkter Zugriff von Anwenderprogrammen auf Hardware nur in Ausnahmefällen sinnvoll / möglich:

Mehr

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen

Betriebssysteme. 4y Springer. Eine kompakte Einführung mit Linux. Albrecht Achilles. Mit 31 Abbildungen Albrecht Achilles 2008 AGI-Information Management Consultants May be used for personal purporses only or by libraries associated to dandelon.com network. Betriebssysteme Eine kompakte Einführung mit Linux

Mehr

Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren. Bruno Kleinert fuddl@gmx.de. 20. Juni 2007

Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren. Bruno Kleinert fuddl@gmx.de. 20. Juni 2007 User Mode Linux (UML) Vortrag zum Seminar Konzepte und Techniken virtueller Maschinen und Emulatoren Friedrich-Alexander-Universität Erlangen-Nürnberg Bruno Kleinert fuddl@gmx.de 20. Juni 2007 Überblick

Mehr

Monitore. Klicken bearbeiten

Monitore. Klicken bearbeiten Sascha Kretzschmann Institut für Informatik Monitore Formatvorlage und deren Umsetzung des Untertitelmasters durch Klicken bearbeiten Inhalt 1. Monitore und Concurrent Pascal 1.1 Warum Monitore? 1.2 Monitordefinition

Mehr

Prozesse und Scheduling

Prozesse und Scheduling Betriebssysteme für Wirtschaftsinformatiker SS04 KLAUSUR Vorbereitung mit Lösungen / Blatt 1 Prozesse und Scheduling Aufgabe 1 : Scheduling Gegeben seien die folgenden Prozesse und die Längen des jeweiligen

Mehr

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161?

Was machen wir heute? Betriebssysteme Tutorium 2. Organisatorisches. Frage 2.1.a. Theorieblätter Abgabe. Antwort. Probleme mit OS/161? Was machen wir heute? Betriebssysteme Tutorium 2 Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität Karlsruhe (TH) 1

Mehr

Round-Robin Scheduling (RR)

Round-Robin Scheduling (RR) RR - Scheduling Reigen-Modell: einfachster, ältester, fairster, am weitesten verbreiteter Algorithmus Entworfen für interaktive Systeme (preemptives Scheduling) Idee: Den Prozessen in der Bereitschaftsschlange

Mehr

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss

Systeme 1. Kapitel 6. Nebenläufigkeit und wechselseitiger Ausschluss Systeme 1 Kapitel 6 Nebenläufigkeit und wechselseitiger Ausschluss Threads Die Adressräume verschiedener Prozesse sind getrennt und geschützt gegen den Zugriff anderer Prozesse. Threads sind leichtgewichtige

Mehr

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 4 Prozesse. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 4 Prozesse Maren Bennewitz Version 20.11.2013 1 Begrüßung Heute ist Tag der offenen Tür Willkommen allen Schülerinnen und Schülern! 2 Wdhlg.: Attributinformationen in

Mehr

Dämon-Prozesse ( deamon )

Dämon-Prozesse ( deamon ) Prozesse unter UNIX - Prozessarten Interaktive Prozesse Shell-Prozesse arbeiten mit stdin ( Tastatur ) und stdout ( Bildschirm ) Dämon-Prozesse ( deamon ) arbeiten im Hintergrund ohne stdin und stdout

Mehr

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4

Mainframe Internet Integration. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013. WebSphere Application Server Teil 4 UNIVERSITÄT LEIPZIG Mainframe Internet Integration Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth SS2013 WebSphere Application Server Teil 4 Leistungsverhalten el0100 copyright W. G. Spruth,

Mehr

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab

OSEK-OS. Oliver Botschkowski. oliver.botschkowski@udo.edu. PG AutoLab Seminarwochenende 21.-23. Oktober 2007. AutoLab OSEK-OS Oliver Botschkowski oliver.botschkowski@udo.edu PG Seminarwochenende 21.-23. Oktober 2007 1 Überblick Einleitung Motivation Ziele Vorteile Einführung in OSEK-OS Architektur Task Management Interrupt

Mehr

Einführung in die technische Informatik

Einführung in die technische Informatik Einführung in die technische Informatik Christopher Kruegel chris@auto.tuwien.ac.at http://www.auto.tuwien.ac.at/~chris Betriebssysteme Aufgaben Management von Ressourcen Präsentation einer einheitlichen

Mehr

PARAGON SYSTEM UPGRADE UTILITIES

PARAGON SYSTEM UPGRADE UTILITIES PARAGON SYSTEM UPGRADE UTILITIES VIRTUALISIERUNG EINES SYSTEMS AUS ZUVOR ERSTELLTER SICHERUNG 1. Virtualisierung eines Systems aus zuvor erstellter Sicherung... 2 2. Sicherung in eine virtuelle Festplatte

Mehr

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum

Moderne Betriebssysteme. Kapitel 8. Kapitel 8. Folie: 1. Multiprozessorsysteme. Autor: Andrew S. Tanenbaum Moderne Betriebssysteme Kapitel 8 Multiprozessorsysteme Kapitel 8 Folie: 1 Multiprozessorsysteme Autor: Andrew S. Tanenbaum Pearson Studium 2009 2 3 4 5 6 7 Betriebssystemarten für Multiprozessoren Jede

Mehr

Performance Messungen von FreeRTOS und

Performance Messungen von FreeRTOS und Performance Messungen von FreeRTOS und µc/os-iii auf ARM-Architekturen Tim Wacher (wht4@bfh.ch) Master of Science in Engineering MRU Production Technology 16. August 2011/ CH-3400 Burgdorf Outline 1 Ziel

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2011 CS104 Programmieren II / CS108 Programmier-Projekt Java-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante

Mehr

Prozesse und Prozessmanagement des BS. 1 Unterschied Prozess, Threads. 1.1 Prozess. 1.2 Threads

Prozesse und Prozessmanagement des BS. 1 Unterschied Prozess, Threads. 1.1 Prozess. 1.2 Threads Prozesse und Prozessmanagement des BS 1 Unterschied Prozess, Threads 1.1 Prozess Bei jedem Programm muss gespeichert werden, welche Betriebsmittel (Speicherplatz, CPU- Zeit, CPU-Inhalt,...) es benötigt.

Mehr

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind

Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Betriebssysteme Systemprogramme bezeichnen alle Programme, die bestimmte Aufgaben unterstützen, die unabhängig von einer konkreten Anwendung sind Umfaßt z.b. auch Compiler, Interpreter und Dienstprogramme

Mehr

U6-1 Organisatories. U6-2 Motivation von Threads. U6-3 Vergleich von Thread-Konzepten. Organisatorisches

U6-1 Organisatories. U6-2 Motivation von Threads. U6-3 Vergleich von Thread-Konzepten. Organisatorisches U6 6. Übung U6 6. Übung U6-1 Organisatories U6-1 Organisatories Organisatorisches Zusätzliche Tafelübung zur S1-Klaurvorbereitung Besprechung Aufgabe 5 (crawl) OSIX-Threads Motivation Thread-Konzepte am

Mehr

Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun. Übungsklausur

Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun. Übungsklausur Hochschule Mannheim Systemsoftware (SYS) Fakultät für Informatik WS 2008/2009 Christian Baun Übungsklausur Aufgabe 1: Definieren Sie den Begriff der Systemsoftware. Nennen Sie die Aufgaben und Komponenten

Mehr

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation

Inhaltsverzeichnis. 2.4 Thread-Systeme. 2.1 Was ist ein Prozess? 2.2 Scheduling. 2.3 Interprozesskommunikation Inhaltsverzeichnis Systemprogrammierung - Kapitel 2 Prozessverwaltung 1/21 2.1 Was ist ein Prozess? Definition Prozesszustände Prozesskontrollblöcke 2.4 Thread-Systeme Sinn und Zweck Thread-Arten Thread-Management

Mehr

Smartphone Entwicklung mit Android und Java

Smartphone Entwicklung mit Android und Java Smartphone Entwicklung mit Android und Java predic8 GmbH Moltkestr. 40 53173 Bonn Tel: (0228)5552576-0 www.predic8.de info@predic8.de Was ist Android Offene Plattform für mobile Geräte Software Kompletter

Mehr

Prozesse und Logs Linux-Kurs der Unix-AG

Prozesse und Logs Linux-Kurs der Unix-AG Prozesse und Logs Linux-Kurs der Unix-AG Andreas Teuchert 27./28. Juni 2012 Prozesse unter Linux gestartete Programme laufen unter Linux als Prozesse jeder Prozess hat eine eindeutige Prozess-ID (PID)

Mehr

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper

Betriebssysteme. Dipl.-Ing.(FH) Volker Schepper 1. Der Prozess beginnt im Zustand Erzeugt, nachdem sein Vaterprozess den Systemaufruf fork() (s.u.) abgesetzt hat. In diesem Zustand wird der Prozess-Kontext initialisiert. 2. Ist diese Aufbauphase abgeschlossen,

Mehr

PThreads. Pthreads. Jeder Hersteller hatte eine eigene Implementierung von Threads oder light weight processes

PThreads. Pthreads. Jeder Hersteller hatte eine eigene Implementierung von Threads oder light weight processes PThreads Prozesse und Threads Ein Unix-Prozess hat IDs (process,user,group) Umgebungsvariablen Verzeichnis Programmcode Register, Stack, Heap Dateideskriptoren, Signale message queues, pipes, shared memory

Mehr

Einführung in git. Ben Oswald. 27. April 2014. Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen

Einführung in git. Ben Oswald. 27. April 2014. Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen Einführung in git Im Rahmen der Vorlesung Entwicklung mobiler Anwendungen Ben Oswald 27. April 2014 Inhaltsverzeichnis 1 Einleitung 1 1.1 Was ist git?..................................... 1 1.2 Warum sollten

Mehr

Musterlösung Klausur SS 2004

Musterlösung Klausur SS 2004 Musterlösung Klausur SS 2004 Fachrichtung: Informatik Lehrveranstaltung: Verteilte Systeme Dozent: Prof. G. Bengel Tag: 15.6.04 Bearbeitungszeit: 90 Minuten Name:... Matr.Nr.:... Punkte:... Note:... Hilfsmittel:

Mehr

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8

Byte-Taxi. Bedienungsanleitung. Seite 1 von 8 Byte-Taxi Bedienungsanleitung Seite 1 von 8 Inhaltsverzeichnis 1. Beschreibung 3 2. Systemvoraussetzungen 4 3. Installationsanleitung 5 4. Bedienung 6 5. Infos & Kontakt 8 Seite 2 von 8 1. Beschreibung

Mehr

Nutzerhandbuch Softwaresystem Inspirata. Benutzerhandbuch Softwaresystem Inspirata

Nutzerhandbuch Softwaresystem Inspirata. Benutzerhandbuch Softwaresystem Inspirata Benutzerhandbuch Softwaresystem Inspirata 1 Inhaltsverzeichnis 1. Login und Logout... 3 2. Kalender/Buchungen auswählen... 5 3. Betreuer... 7 3.1 Buchung anlegen... 7 3.2 Betreuer zuordnen... 8 3.3 Notiz

Mehr

Prozesse und Logs Linux-Kurs der Unix-AG

Prozesse und Logs Linux-Kurs der Unix-AG Prozesse und Logs Linux-Kurs der Unix-AG Benjamin Eberle 22. Januar 2015 Prozesse unter Linux gestartete Programme laufen unter Linux als Prozesse jeder Prozess hat eine eindeutige Prozess-ID (PID) jeder

Mehr

Embedded-Linux-Seminare. Linux als Betriebssystem

Embedded-Linux-Seminare. Linux als Betriebssystem Embedded-Linux-Seminare Linux als Betriebssystem http://www.embedded-linux-seminare.de Diplom-Physiker Peter Börner Spandauer Weg 4 37085 Göttingen Tel.: 0551-7703465 Mail: info@embedded-linux-seminare.de

Mehr

Visualisierung paralleler bzw. verteilter Programme

Visualisierung paralleler bzw. verteilter Programme Seminar Visualisierung in Informatik und Naturwissenschaften im SS 1999 Visualisierung paralleler bzw. verteilter Programme Holger Dewes Gliederung Zum Begriff Motivation PARADE Beispiel 1: Thread basierte

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0)

Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) Tapps mit XP-Mode unter Windows 7 64 bit (V2.0) 1 Einleitung... 2 2 Download und Installation... 3 2.1 Installation von WindowsXPMode_de-de.exe... 4 2.2 Installation von Windows6.1-KB958559-x64.msu...

Mehr

6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ

6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ 6RIW&OHDQ Š 9HUVLRQ8SJUDGHDQOHLWXQJ 6HKUJHHKUWH6RIW&OHDQ $QZHQGHU LQ XQVHUHP 6RIW&OHDQ 8SGDWHV 'RZQORDGEHUHLFK ILQGHQ 6LH ]ZHL $UWHQ YRQ 8SGDWHV 1DFKIROJHQGHUIDKUHQ6LHZHOFKHV8SGDWHI U6LHGDVULFKWLJHLVWXQGZLH6LHGDV8SGDWHDXI,KUHP$UEHLWVSODW]GXUFKI

Mehr

SchlieSSen Sie Ihren Lemur an

SchlieSSen Sie Ihren Lemur an 1 SchlieSSen Sie Ihren Lemur an Der Lemur ist nicht irgendein durchschnittlicher MIDI-Controller. Er spricht 1000 Mal schneller und mit der 4-fachen Auflösung. Also finden Sie auf der Rückseite auch nicht

Mehr

juliteccrm Dokumentation

juliteccrm Dokumentation Customer Relationship Management für kleine und mittelständische Unternehmen juliteccrm Dokumentation 2012, julitec GmbH Page 1 of 12 julitec GmbH Flößaustraße 22 a 90763 Fürth Telefon: +49 911 979070-0

Mehr

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme

OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme OSEK / OSEKtime Ausgewählte Kapitel eingebetteter Systeme Wilhelm Haas Wilhelm.Haas@informatik.stud.uni-erlangen.de Friedrich-Alexander-Universität Erlangen-Nürnberg Institut für Informatik Lehrstuhl 4

Mehr

Einrichten eines SSH - Server

Einrichten eines SSH - Server Einrichten eines SSH - Server Um den Server weiter einzurichten bzw. später bequem warten zu können ist es erforderlich, eine Schnittstelle für die Fernwartung / den Fernzugriff zu schaffen. Im Linux -

Mehr

Besprechung Aufgabe 5 (crawl) POSIX-Threads. Problem: UNIX-Prozesskonzept ist für viele heutige Anwendungen unzureichend

Besprechung Aufgabe 5 (crawl) POSIX-Threads. Problem: UNIX-Prozesskonzept ist für viele heutige Anwendungen unzureichend U7 6. Übung U7 6. Übung U7-1 Motivation von Threads U7-1 Motivation von Threads Besprechung Aufgabe 5 (crawl) OSIX-Threads Motivation Thread-Konzepte pthread-ai Koordinierung UNIX-rozesskonzept: eine Ausführungsumgebung

Mehr

Windows CE. Process Control and Robotics. Fabian Garagnon

Windows CE. Process Control and Robotics. Fabian Garagnon Windows CE Process Control and Robotics Fabian Garagnon 14.01.2009 Agenda 3 Geschichte & Timeline Echtzeit & Multithreading Architektur Memory Management & Context Switch Entwicklung unter CE Interrupts

Mehr

VORSTELLUNG DER DIPLOMARBEIT

VORSTELLUNG DER DIPLOMARBEIT 1 VORSTELLUNG DER DIPLOMARBEIT Thomas Werner Inhaltsverzeichnis 2 Thema Aufgabenstellung Anwendungsdebugging Threads Remote Debugging Implementierung Ausblick Quellen 3 Thema Untersuchung von Funktionsabläufen

Mehr

Seminararbeit Embedded Systems - Discovery Mechanismus für sdds. Kevin Sapper

Seminararbeit Embedded Systems - Discovery Mechanismus für sdds. Kevin Sapper Seminararbeit Embedded Systems - Discovery Mechanismus für sdds Kevin Sapper Seminararbeit Embedded Systems - Discovery Mechanismus für sdds Kevin Sapper Table of Contents... v 1. Einführung... 1 2. Grundlagen...

Mehr

Aufgaben: (dazugehörige Kapitel / Seitenangaben in Kursiv: Kapitel Seite Seitennummern)

Aufgaben: (dazugehörige Kapitel / Seitenangaben in Kursiv: Kapitel Seite Seitennummern) Klausur Verteilte Systeme 15.6. R120A 8:00-9:30 5 Aufgaben, 50 Punkte (8 12 pro Aufgabe) 45-50 1.0 44 1.1 35 2.0 25 3.0 15 4.0 http://www.bts.fh-mannheim.de Aufgaben: (dazugehörige Kapitel / Seitenangaben

Mehr

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski

Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS. geschrieben von Oliver Botschkowski Ausarbeitung im Rahmen der PG Autolab zum Thema: OSEK 1 -OS geschrieben von Oliver Botschkowski 1 Offene Systeme und deren Schnittstelle für die Elektronik im Kraftfahrzeug 1 Oliver Botschkowski - OSEK-OS

Mehr

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003

Task A Zündung. Task B Einspritzung. Task C Erfassung Pedalwert. J. Schäuffele, Th. Zurawka: Automotive Software Engineering, Vieweg, 2003 Task! evt. parallel zu bearbeitende Ausführungseinheit! Beispiel: Task A Zündung Task B Einspritzung Task C Erfassung Pedalwert Zeit t J. Schäuffele, Th. Zurawka:, Vieweg, 2003 Echtzeitbetriebssysteme

Mehr

TIMI: Technische Informatik für Medieninformatiker

TIMI: Technische Informatik für Medieninformatiker TIMI: Technische Informatik für Medieninformatiker Bachelor-Studiengang Digitale Medien Medieninformatik SS 2004 Niels Pollem Arbeitsgruppe Rechnernetze (Prof. Dr.-Ing. Ute Bormann) Scheduling:

Mehr

Vorbereitung zur Prüfung Echtzeitbetriebssysteme

Vorbereitung zur Prüfung Echtzeitbetriebssysteme Vorbereitung zur Prüfung Echtzeitbetriebssysteme Zugelassene Hilfsmittel: Taschenrechner Bitte verwenden Sie keinen roten Farbstift! 1. Echtzeitbetriebssysteme - Allgemein (15 Punkte) 1.1. Warum setzen

Mehr

sedex-client Varianten für den Betrieb in einer hoch verfügbaren

sedex-client Varianten für den Betrieb in einer hoch verfügbaren Département fédéral de l'intérieur DFI Office fédéral de la statistique OFS Division Registres Team sedex 29.07.2014, version 1.0 sedex-client Varianten für den Betrieb in einer hoch verfügbaren Umgebung

Mehr

Hardware Virtualisierungs Support für PikeOS

Hardware Virtualisierungs Support für PikeOS Virtualisierungs Support für PikeOS Design eines Virtual Machine Monitors auf Basis eines Mikrokernels Tobias Stumpf SYSGO AG, Am Pfaenstein 14, 55270 Klein-Winternheim HS Furtwangen, Fakultät Computer

Mehr

Installationshandbuch

Installationshandbuch Installationshandbuch Erforderliche Konfiguration Installation und Aktivierung - 1 - Erforderliche Konfiguration Programme der 4D v15 Produktreihe benötigen folgende Mindestkonfiguration: Windows OS X

Mehr

RealTime Linux. Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam

RealTime Linux. Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam RealTime Linux Paul Seidel Seminar Prozessteuerung und Robotik WS 08/09 Lehrstuhl BS und Middleware Prof. Polze Hasso-Plattner-Institut Potsdam Übersicht 2 Standard-Kernel Dual-Kernel RTAI/LXRT In-Kernel

Mehr

User Level Device Driver am Beispiel von TCP

User Level Device Driver am Beispiel von TCP September 17, 2004 Einleitung Motivation für Userlevel Device Driver Probleme von Userlevel Device Driver Motivation für Userlevel Device Driver Modularität, leichterer Austausch/Erneuerung von Komponenten.

Mehr

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008

Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Name: Matrikel-Nr: Prüfung VO Betriebssysteme SS2008 / 7. Juli 2008 Bitte schreiben Sie leserlich und antworten Sie kurz und präzise. 1. Zeichnen Sie das Schichten-Modell eines Computersystems und markieren

Mehr

PROGRAMMIEREN MIT UNIX/LINUX-SYSTEMAUFRUFEN

PROGRAMMIEREN MIT UNIX/LINUX-SYSTEMAUFRUFEN PROGRAMMIEREN MIT UNIX/LINUX-SYSTEMAUFRUFEN 2. UNIX/Linux-Prozessverwaltung und zugehörige Systemaufrufe Wintersemester 2015/16 2. Die UNIX/LINUX-Prozessverwaltung Aufgaben: 1. Erzeugen neuer Prozesse

Mehr

Dokumentation. juris Autologon-Tool. Version 3.1

Dokumentation. juris Autologon-Tool. Version 3.1 Dokumentation juris Autologon-Tool Version 3.1 Inhaltsverzeichnis: 1. Allgemeines... 3 2. Installation Einzelplatz... 3 3. Installation Netzwerk... 3 4. Konfiguration Netzwerk... 3 4.1 Die Autologon.ini...

Mehr

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET

SurefireKernel ÜBERSICHT SPEZIFIKATION. www.triadem.ch. Sicherheitskernel DATASHEET Sicherheitskernel ÜBERSICHT SurefireKernel ist ein schlanker skalierbarer nicht preemptiver Echtzeit-Kernel der für den Einsatz auf Kontrollersysteme optimiert ist. Er verfügt über eine Realtime-Überwachung

Mehr

9 Multithreading. 1 Idee des Multithreading

9 Multithreading. 1 Idee des Multithreading 9 Multithreading Jörn Loviscach Versionsstand: 21. Juli 2015, 11:50 Die nummerierten Felder sind absichtlich leer, zum Ausfüllen beim Ansehen der Videos: http://www.j3l7h.de/videos.html This work is licensed

Mehr

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort

Was machen wir heute? Betriebssysteme Tutorium 12. Organisatorisches. Frage 12.1.a. Programmieraufgaben Vorstellung. Antwort Was machen wir heute? Betriebssysteme Tutorium 12 1 Organisatorisches Philipp Kirchhofer philipp.kirchhofer@student.kit.edu http://www.stud.uni-karlsruhe.de/~uxbtt/ Lehrstuhl Systemarchitektur Universität

Mehr

MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29)

MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29) MySQL Community Server 5.6 Installationsbeispiel (Ab 5.5.29) Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der

Mehr

Rollen- und Rechtekonzept

Rollen- und Rechtekonzept Inhaltsverzeichnis Rollen- und Rechtekonzept 1. Ziele...1 2. Konzeption zur Realisierung durch Access Control List und im Management-Interface...2 2.1. Ansatz...2 2.2. Safety oder Security...2 2.3. User-

Mehr

Software-Projekt: Mensch ärgere Dich nicht. Dokumentation Softwareprojekt: Mensch ärgere Dich nicht

Software-Projekt: Mensch ärgere Dich nicht. Dokumentation Softwareprojekt: Mensch ärgere Dich nicht Dokumentation Softwareprojekt: Mensch ärgere Dich nicht Das Programm Mensch ärgere Dich nicht ermöglicht das Spielen des gleichnamigen Spieles über Netzwerke. Jeder Spieler verfügt dabei über einen Clienten,

Mehr

Kalendersynchronisation

Kalendersynchronisation Seite 1 Kalendersynchronisation Der Email-Mania Website bietet die Möglichkeit, Termine, Aufgaben und Notizen zentral zu verwalten und mit Thunderbird, Outlook oder Handies zu synchronisieren. Wie das

Mehr

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002

Die L4-Mikrokern. Mikrokern-Familie. Hauptseminar Ansätze für Betriebssysteme der Zukunft. Michael Steil. Michael Steil 18.04.2002 Die L4-Mikrokern Mikrokern-Familie Hauptseminar Ansätze für Betriebssysteme der Zukunft 18.04.2002 Folie 1 Aufbau des Vortrags 1. Mikrokerne: Idee und Geschichte 2. L4: ein schneller Mikrokern 3. L4Linux:

Mehr

Nebenläufige Programmierung

Nebenläufige Programmierung Nebenläufige Programmierung Perspektiven der Informatik 27. Januar 2003 Gert Smolka Telefon-Szenario Eine Telefonzelle Mehrere Personen wollen telefonieren Immer nur eine Person kann telefonieren Ressource

Mehr

POSIX Echtzeit: Kernel 2.6 und Preempt-RT

POSIX Echtzeit: Kernel 2.6 und Preempt-RT POSIX Echtzeit: Kernel 2.6 und Preempt-RT Slide 1 - http://www.pengutronix.de - 21.01.2007 Echtzeit-Systemplanung Wenn das zeitliche Verhalten spezifiziert ist, kann auch spezifiziert werden, welche Applikationsteile

Mehr

Prozessarchitektur einer Oracle-Instanz

Prozessarchitektur einer Oracle-Instanz 6. Juni 2008 Inhaltsverzeichnis Oracle Instanz 1 Oracle Instanz 2 3 Redo Log Buffer Shared Pool Java Pool & Large Pool Oracle Instanz Eine Oracle-Instanz ist Hauptbestandteil des Oracle Datenbank Management

Mehr

Client/Server-Systeme

Client/Server-Systeme Frühjahrsemester 2013 CS108 Programmier-Projekt Kapitel 3: /Server-Architekturen H. Schuldt /Server-Systeme Ein zweischichtiges /Server-System ist die einfachste Variante eines verteilten Systems (also

Mehr

leave: mov flag, 0 ; 0 in flag speichern: Lock freigeben ret

leave: mov flag, 0 ; 0 in flag speichern: Lock freigeben ret Sep 19 14:20:18 amd64 sshd[20494]: Accepted rsa for esser from ::ffff:87.234.201.207 port 61557 Sep 19 14:27:41 amd64 syslog-ng[7653]: STATS: dropped 0 Sep 20 01:00:01 amd64 /usr/sbin/cron[29278]: (root)

Mehr

Dialekte der Klimaforschung

Dialekte der Klimaforschung Dialekte der Klimaforschung Vom Fortran-Programm zum parallelen Programm Thomas Ludwig Inhalt Welche Dialekte werden transformiert? Welche Anforderungen stellen wir? Wozu diese Transformation? Wie ist

Mehr

Installieren und Einrichten von VirtualBox für TAPPS (V1.0)

Installieren und Einrichten von VirtualBox für TAPPS (V1.0) Installieren und Einrichten von VirtualBox für TAPPS (V1.0) 1 Einleitung... 2 2 Download und Installation... 2 3 Einrichten von VirtualBox am Beispiel Windows XP... 7 4 Einrichten von Windows XP... 26

Mehr

Informationen zum Kopierschutz

Informationen zum Kopierschutz Analyser AutoSPy Informationen zum Kopierschutz Der Analyser AutoSPy verfügt über einen Kopierschutz, der unerlaubtes Erzeugen und Vervielfältigen von Lizenzen verhindert. Dieses Dokument soll Ihnen den

Mehr

Systeme 1. Kapitel 5. Scheduling

Systeme 1. Kapitel 5. Scheduling Systeme 1 Kapitel 5 Scheduling Scheduling Verteilung und Zuweisung von begrenzten Ressourcen an konkurrierende Prozesse Beispiel: -> Zeitablaufsteuerung Zwei Prozesse zur gleichen Zeit rechenbereit auf

Mehr

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH

ARM Cortex-M Prozessoren. Referat von Peter Voser Embedded Development GmbH ARM Cortex-M Prozessoren Referat von Peter Voser Embedded Development GmbH SoC (System-on-Chip) www.embedded-development.ch 2 Instruction Sets ARM, Thumb, Thumb-2 32-bit ARM - verbesserte Rechenleistung

Mehr

Redwood Cronacle und REALTECH theguard! Integration

Redwood Cronacle und REALTECH theguard! Integration Redwood Cronacle und REALTECH theguard! Integration Einleitung Redwood Software und REALTECH haben gemeinsam eine Lösung entwickelt, die die Systemverfügbarkeit von SAP und mysap Systemen signifikant erhöht.

Mehr

Anwenderdokumentation

Anwenderdokumentation Anwenderdokumentation SAP Supplier Lifecycle Management SAP SLC 1.0 SP02 Alle Rechte vorbehalten Inhaltsverzeichnis 1 SAP Supplier Lifecycle Management (SAP SLC)... Fehler! Textmarke nicht definiert. 1

Mehr

Fresh Minder 3-Server

Fresh Minder 3-Server Fresh Minder 3-Server Installation und Betrieb Fresh Minder-Vertrieb Rieslingweg 25 D - 74354 Besigheim support@freshminder.de www.freshminder.de ÜBERSICHT Die Standardversion (Einzelplatzversion) von

Mehr

Game Engine Architecture and Development. Platform Unabhängiger Code Multi Threading in Game Engines Profiling

Game Engine Architecture and Development. Platform Unabhängiger Code Multi Threading in Game Engines Profiling Game Engine Architecture and Development Platform Unabhängiger Code Multi Threading in Game Engines Profiling Folien Die Folien werden auf acagamics.de hochgeladen Das Passwort ist 60fps (ohne ) Rückblick:

Mehr

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Institut für Informatik Prof. Dr. Bernhard Bauer Stephan Roser Viviane Schöbel Wintersemester 07/08 Übungsblatt 5 08.01.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1:

Mehr

SMC Integrationsserver 5.0 Versionsinformationen

SMC Integrationsserver 5.0 Versionsinformationen SMC Integrationsserver 5.0 Versionsinformationen SMC IT AG Pröllstraße 24 86157 Augsburg Tel. (0821) 720 62-0 Fax. (0821) 720 62-62 smc-it.de info@smc-it.de Geschäftsstelle Ettlingen Pforzheimer Straße

Mehr

Implementation of a Framework Component for Processing Tasks within Threads on the Application Level

Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Implementation of a Framework Component for Processing Tasks within Threads on the Application Level Deutsches Krebsforschungszentrum, for Processing Task within Threads on the Application Level Motivation

Mehr

Programme deinstallieren,

Programme deinstallieren, Programme deinstallieren, Programme mit Windows deinstallieren: Sie haben Programme auf Ihrem Rechner, die Sie gar nicht oder nicht mehr gebrauchen. Sie sollten solche Programme deinstallieren, denn die

Mehr

Byte-Taxi. Bedienungsanleitung. Autor: Dimitrios Savvidis

Byte-Taxi. Bedienungsanleitung. Autor: Dimitrios Savvidis Byte-Taxi Bedienungsanleitung Autor: Dimitrios Savvidis Inhaltsverzeichnis 1. Beschreibung 1 2. Systemvoraussetzungen 2 3. Installationsanleitung 3 4. Bedienung 5 5. Infos & Kontakt 8 1. Beschreibung Byte-Taxi

Mehr

DHCP. DHCP Theorie. Inhalt. Allgemein. Allgemein (cont.) Aufgabe

DHCP. DHCP Theorie. Inhalt. Allgemein. Allgemein (cont.) Aufgabe 23. DECUS München e.v. Symposium 2000 Bonn Norbert Wörle COMPAQ Customer Support Center Inhalt Theorie Allgemein Aufgabe von Vorteile / Nachteile Wie bekommt seine IP Adresse? Wie wird Lease verlängert?

Mehr

Übung zu Grundlagen der Betriebssysteme. 10. Übung 18.12.2012

Übung zu Grundlagen der Betriebssysteme. 10. Übung 18.12.2012 Übung zu Grundlagen der Betriebssysteme 10. Übung 18.12.2012 Aufgabe 1 a) Was versteht man unter einem kritischen Abschnitt oder kritischen Gebiet (critical area)? b) Welche Aufgabe hat ein Semaphor? c)

Mehr

Übersicht. Nebenläufige Programmierung. Praxis und Semantik. Einleitung. Sequentielle und nebenläufige Programmierung. Warum ist. interessant?

Übersicht. Nebenläufige Programmierung. Praxis und Semantik. Einleitung. Sequentielle und nebenläufige Programmierung. Warum ist. interessant? Übersicht Aktuelle Themen zu Informatik der Systeme: Nebenläufige Programmierung: Praxis und Semantik Einleitung 1 2 der nebenläufigen Programmierung WS 2011/12 Stand der Folien: 18. Oktober 2011 1 TIDS

Mehr

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren

Whitepaper. Produkt: combit Relationship Manager / address manager. FILESTREAM für Microsoft SQL Server aktivieren combit GmbH Untere Laube 30 78462 Konstanz Whitepaper Produkt: combit Relationship Manager / address manager FILESTREAM für Microsoft SQL Server aktivieren FILESTREAM für Microsoft SQL Server aktivieren

Mehr

Mac Quick Guide für die Migration zum HIN Client

Mac Quick Guide für die Migration zum HIN Client Mac Quick Guide für die Migration zum HIN Client Anleitung zur Migration vom ASAS Client zum neuen HIN Client in Schritten:. Schritt 2. Schritt. Schritt Installation HIN Client Software Installiert die

Mehr