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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

13. Übung mit Musterlösung

13. Übung mit Musterlösung 13. Übung mit Musterlösung 1 Lösung 1 Teil 1.Multiple Choice) Bewertung: Ein Punkt für richtige Antwort, für jede falsche Antwort ein Punktabzug. a) Für die Exponentialverteilung ist die Zeit bis zum nächsten

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

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

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

Echtzeit-Linux mit dem RT-Preemption-Patch

Echtzeit-Linux mit dem RT-Preemption-Patch Echtzeit-Linux mit dem RT-Preemption-Patch IT-Klinger Andreas Klinger ak@it-klingerde 22072008 Der RT-Preemption-Patch integriert sich beinahe nahtlos in den Standard-Kernel und bietet Echtzeitfähigkeit

Mehr

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance

Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance Rechnerarchitektur und Betriebssysteme (CS201): Semaphor, Monitor, Deadlocks, Re-Entrance 5. November 2013 Prof. Dr. Christian Tschudin Departement Mathematik und Informatik, Universität Basel Repetition

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

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

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation

Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation Architektur Verteilter Systeme Teil 6: Interprozess-Kommunikation 09.05.15 1 Literatur [6-1] http://php.net/manual/de/book.sockets.php [6-2] http://de.wikipedia.org/wiki/socket_(software) [6-3] http://php.net/manual/de/book.network.php

Mehr

Einführung in die Echtzeitbetriebssysteme

Einführung in die Echtzeitbetriebssysteme Einführung in die Echtzeitbetriebssysteme Hauptseminararbeit in dem Studiengang B.Sc. Informatik von Maximilian von Piechowski Technische Hochschule Mittelhessen Inhaltsverzeichnis 1 Was versteht man unter

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

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

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

Implementierung Echtzeitbetriebssysteme Architektur eines RTOS am Beispiel Windows CE 23.03.2010 Autor: Rudi Swiontek und Ralf Ebert*

Implementierung Echtzeitbetriebssysteme Architektur eines RTOS am Beispiel Windows CE 23.03.2010 Autor: Rudi Swiontek und Ralf Ebert* Implementierung Echtzeitbetriebssysteme Architektur eines RTOS am Beispiel Windows CE 23.03.2010 Autor: Rudi Swiontek und Ralf Ebert* Echtzeitbetriebssysteme, kurz RTOS, besitzen neben harter Echtzeitfähigkeit

Mehr

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte

Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Entwicklung eines Mac OS X Treibers für eine PCI-VME Interface Karte Matthias Lange Informatikstudent, TU-Dresden 27. September 2005 http://www.matze-lange.de Warum entwickelt jemand einen Treiber für

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

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

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Einführung... 2-3 Servereinstellungen für die Einrichtung auf dem E-Mail Client... 4 E-Mail Adresse / Postfach einrichten...

Mehr

VxWorks - Aufbau und Programmierung

VxWorks - Aufbau und Programmierung VxWorks - Aufbau und Programmierung Dominik Meyer AG Echtzeitsysteme / Eingebettete Systeme Institut für Informatik Christian-Albrechts-Universität zu Kiel Zusammenfassung

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

Echtzeitanforderung und Linux

Echtzeitanforderung und Linux Echtzeitanforderung und Linux Slide 1 - http://www.pengutronix.de - 21.01.2007 Definition Harte Echtzeit I Was zeichnet ein Echtzeitsystem aus? Zeitverhalten ist Teil der System-Spezifikation! Bei Embedded-Systemen

Mehr

Übersicht der 10 relevanten Realtime Betriebssysteme. Urs Böhm/31.August 2010

Übersicht der 10 relevanten Realtime Betriebssysteme. Urs Böhm/31.August 2010 Übersicht der 10 relevanten Realtime Betriebssysteme Urs Böhm/31.August 2010 Übersicht Wann ist ein Betriebssystem Echtzeitfähig -und wann nicht? Warum gibt es so viele RTOS? Verschiedene Einsatzgebiete

Mehr

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik)

CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Prof. Dr. Th. Letschert CS2101 Nebenläufige und Verteilte Programme Bachelor of Science (Informatik) Vorlesung 7 Th Letschert FH Gießen-Friedberg Ressourcen Verwaltung passive Ressourcen aktive Ressourcen

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

Embedded OS für ARM Cortex Microcontroller

Embedded OS für ARM Cortex Microcontroller Embedded OS für ARM Cortex Microcontroller RTOS Design, Timinganalyse und Test mit Core Simulation und Hardware Debugger Entscheidende Fragen für oder gegen RTOS Lohnt sich der Einsatz eines RTOS auch

Mehr

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel

Welche der folgenden Aussagen gelten? a) Im allgemeinen gilt: ein Deadlock tritt auf gdw. der Resource-Allocation Graph einen Zykel Aufgabe 1 (5 Punkte) (Multiple Choice) Beantworten Sie folgende Fragen durch Ankreuzen der richtigen Antwort. Für jede falsche Antwort wird ein Punkt abgezogen (es werden minimal 0 Punkte vergeben). Welche

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

Benutzerhandbuch für FaxClient für HylaFAX

Benutzerhandbuch für FaxClient für HylaFAX Benutzerhandbuch für FaxClient für HylaFAX Vielen Dank, daß Sie entschlossen haben, dieses kleine Handbuch zu lesen. Es wird Sie bei der Installation und Benutzung des FaxClients für HylaFAX unterstützen.

Mehr

Treiber Fortgeschrittene Konzepte

Treiber Fortgeschrittene Konzepte Treiber Fortgeschrittene Konzepte Dr.-Ing. Matthias Sand Lehrstuhl für Informatik 3 (Rechnerarchitektur) Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2010/2011 Treiber Fortgeschrittene Konzepte

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

B1 Stapelspeicher (stack)

B1 Stapelspeicher (stack) B1 Stapelspeicher (stack) Arbeitsweise des LIFO-Stapelspeichers Im Kapitel "Unterprogramme" wurde schon erwähnt, dass Unterprogramme einen so genannten Stapelspeicher (Kellerspeicher, Stapel, stack) benötigen

Mehr

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien

Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Friedrich-Alexander-Universität Erlangen-Nürnberg Ausgewählte Kapitel eingebetteter Systeme Echtzeitfähige Ereignisgetriebene Scheduling-Strategien Sven Kerschbaum 1. Einführung Bei einem eingebetteten

Mehr

DATENBLATT IDEE ZIELE LÖSUNG VORTEILE VORAUSSETZUNGEN. www.nospamproxy.de

DATENBLATT IDEE ZIELE LÖSUNG VORTEILE VORAUSSETZUNGEN. www.nospamproxy.de www.nospamproxy.de Net at Work Netzwerksysteme GmbH Am Hoppenhof 32, D-33104 Paderborn Tel. +49 5251 304-600, Fax -650 info@netatwork.de www.netatwork.de DIE IDEE Der Anlass zu entwickeln, ist der gestiegene

Mehr

Einführung in die OPC-Technik

Einführung in die OPC-Technik Einführung in die OPC-Technik Was ist OPC? OPC, als Standartschnittstelle der Zukunft, steht für OLE for Process Control,und basiert auf dem Komponentenmodel der Firma Microsoft,dem Hersteller des Betriebssystems

Mehr

Gefahren aus dem Internet 6 Aktive Angriffe April 2010

Gefahren aus dem Internet 6 Aktive Angriffe April 2010 6 Aktive Angriffe Lernziele Sie können grob erklären, wie ein Angreifer in Ihren Computer eindringen kann. Sie können herausfinden, welche Ports auf Ihrem Computer offen sind. Sie wissen, warum der Einsatz

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

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18

UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 UI-Testing mit Microsoft Test Manager (MTM) Philip Gossweiler / 2013-04-18 Software Testing Automatisiert Manuell 100% 70% 1 Überwiegender Teil der Testing Tools fokusiert auf automatisiertes Testen Microsoft

Mehr

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar "Eingebettete drahtlose Systeme"

Embedded Linux. Embedded Linux. Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de. Seminar Eingebettete drahtlose Systeme Daniel Buchheim daniel.buchheim@informatik.tu-cottbus.de Embedded Linux 30.01.2009 Daniel Buchheim Inhalt: Was ist Embedded Linux? Hardwareunterstützung in Eingebetteten Systemen Open Source Aspekte Aufbau

Mehr

Kernel Programmierung unter Linux. Programmierung von Kernelmodulen. Referent Klaus Ruhwinkel

Kernel Programmierung unter Linux. Programmierung von Kernelmodulen. Referent Klaus Ruhwinkel Kernel Programmierung unter Linux Programmierung von Kernelmodulen Referent Klaus Ruhwinkel Das Betriebssystem Aufbau des Betriebssystem: Es besteht aus den Betriebssystemkern und den sonstigen Betriebssystemkomponenten

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

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN

whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN whitepaper CLOUD-ENTWICKLUNG: BESTE METHODEN UND SUPPORT-ANWENDUNGEN CLOUD-ENTWICKLUNG: BESTE METHODEN 1 Cloud-basierte Lösungen sind auf dem IT-Markt immer weiter verbreitet und werden von immer mehr

Mehr

Seminararbeit Ruby Uno Kartenspiel

Seminararbeit Ruby Uno Kartenspiel Seminararbeit Ruby Uno Kartenspiel Autor: Fabian Merki Fabian Merki 05.11.2006 1 von 10 Inhaltsverzeichnis Einleitung... 3 Die Idee... 4 Design und Implementierung in Ruby... 5 Testing... 7 Startbefehle...

Mehr

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format

CompuLok Zentrale. Software Interface. Digitalzentrale für DCC und Motorola Format CompuLok Zentrale Software Interface Digitalzentrale für DCC und Motorola Format Inhalt CompuLok Software Interface... 3 Das Software Interface... 3 Installation... 3 Treiber installieren.... 3 Hinweis

Mehr

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Military Air Systems

Military Air Systems Trennung von Applikationen unterschiedlicher Kritikalität in der Luftfahrt durch Software en am Beispiel des Real-time Operating Systems PikeOS Dr. Bert Feldmann DGLR Workshop Garching, 09.10.2007 Seite

Mehr

Echtzeitbetriebssysteme

Echtzeitbetriebssysteme Echtzeitbetriebssysteme QNX 409 Geschichte: Einführung 1980 entwickeln Gordon Bell und Dan Dodge ein eigenes Echtzeitbetriebssystem mit Mikrokernel. QNX orientiert sich nicht an Desktopsystemen und breitet

Mehr

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH

Autor: Michael Spahn Version: 1.0 1/10 Vertraulichkeit: öffentlich Status: Final Metaways Infosystems GmbH Java Einleitung - Handout Kurzbeschreibung: Eine kleine Einführung in die Programmierung mit Java. Dokument: Autor: Michael Spahn Version 1.0 Status: Final Datum: 23.10.2012 Vertraulichkeit: öffentlich

Mehr

Anleitung für zwei C++ - Openmp - Beispiele auf der NWZSuperdome

Anleitung für zwei C++ - Openmp - Beispiele auf der NWZSuperdome Anleitung für zwei C++ - Openmp - Beispiele auf der NWZSuperdome (Timo Heinrich, t_hein03@uni-muenster.de) Inhaltsverzeichnis: 0.Einleitung 1.Teil: Helloworldprogramm 1.1 Quellcode: Helloworld.cpp 1.2

Mehr

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012

Übung zu Grundlagen der Betriebssysteme. 7. Übung 27.11.2012 Übung zu Grundlagen der Betriebssysteme 7. Übung 27.11.2012 Threads Thread (Faden des (Kontrollflusses)): ist ein sequentieller Abarbeitungsablauf (Kontrollfluss) innerhalb eines Prozesses. Umfasst ein

Mehr

Einführung in UNIX 1. Das Betriebssystem UNIX ist fähig, mehrere Aufgaben scheinbar gleichzeitig zu erledigen. Dies wird mit Multitasking bezeichnet.

Einführung in UNIX 1. Das Betriebssystem UNIX ist fähig, mehrere Aufgaben scheinbar gleichzeitig zu erledigen. Dies wird mit Multitasking bezeichnet. Einführung in UNIX 1 7 Prozesse Das Betriebssystem UNIX ist fähig, mehrere Aufgaben scheinbar gleichzeitig zu erledigen. Dies wird mit Multitasking bezeichnet. Auf einem UNIX-Rechner können hundert oder

Mehr

PARAGON Encrypted Disk

PARAGON Encrypted Disk PARAGON Encrypted Disk Anwenderhandbuch Paragon Technologie, Systemprogrammierung GmbH Copyright Paragon Technologie GmbH Herausgegeben von Paragon Technologie GmbH, Systemprogrammierung Pearl-Str. 1 D-79426

Mehr

.htaccess HOWTO. zum Schutz von Dateien und Verzeichnissen mittels Passwortabfrage

.htaccess HOWTO. zum Schutz von Dateien und Verzeichnissen mittels Passwortabfrage .htaccess HOWTO zum Schutz von Dateien und Verzeichnissen mittels Passwortabfrage Stand: 21.06.2015 Inhaltsverzeichnis 1. Vorwort...3 2. Verwendung...4 2.1 Allgemeines...4 2.1 Das Aussehen der.htaccess

Mehr

Parallelverarbeitung mit Ruby

Parallelverarbeitung mit Ruby Fachhochschule Wiesbaden - Fachbereich DCSM Parallelverarbeitung mit Ruby Prozess-Ebene Multithreading 04.12.2008 2003, 2008 H. Werntges, FB Design Informatik Medien (DCSM), FH Wiesbaden 1 Fachhochschule

Mehr

Enterprise Java Beans Einführung

Enterprise Java Beans Einführung Enterprise Java Beans Einführung Vorlesung 8 Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht EJBs im JEE Umfeld Verschiedene Typen von EJBs Von der Javaklasse

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Betriebssystem-basierte Virtualisierung

Betriebssystem-basierte Virtualisierung Betriebssystem-basierte Virtualisierung Dr.-Ing. Volkmar Sieh Department Informatik 3: Rechnerarchitektur Friedrich-Alexander-Universität Erlangen-Nürnberg WS 2011/2012 Betriebssystem-basierte Virtualisierung

Mehr

Serverumzug mit Win-CASA

Serverumzug mit Win-CASA Serverumzug mit Win-CASA Wenn Sie in Ihrem Netzwerk einen Umzug der Server-Version durchführen müssen, sollten Sie ein paar Punkte beachten, damit dies ohne Probleme abläuft. 1. Nachweis-Ordner In der

Mehr

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz

Systeme I: Betriebssysteme Kapitel 7 Scheduling. Maren Bennewitz Systeme I: Betriebssysteme Kapitel 7 Scheduling Maren Bennewitz Version 23.01.2013 1 Inhalt Vorlesung Aufbau einfacher Rechner Überblick: Aufgabe, Historische Entwicklung, unterschiedliche Arten von Betriebssystemen

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

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

DeskSave 8.2. - Aufruf mit Kommandozeilenparametern möglich - Automatisches Restaurieren bei Auflösungswechsel, Programmstart oder Rückkehr aus

DeskSave 8.2. - Aufruf mit Kommandozeilenparametern möglich - Automatisches Restaurieren bei Auflösungswechsel, Programmstart oder Rückkehr aus DeskSave 8.2 (c) 1998-2008 Thorsten Blauhut DeskSave ist ein anwenderfreundliches Tool, mit dem man das Icon-Layout des Desktops sichern und bei Bedarf wieder restaurieren kann. Eigenschaften: - Sicherung

Mehr

Beispiel droidremoteppt

Beispiel droidremoteppt Arthur Zaczek Nov 2014 1 Beispiel droidremoteppt 1.1 Beschreibung Powerpoint soll mit ein Android Handy über Bluetooth gesteuert werden Folien wechseln (Vor/Zurück) Folien am Handy darstellen Am Handy

Mehr

Installationsanleitung Netzwerklizenzen Vectorworks 2014

Installationsanleitung Netzwerklizenzen Vectorworks 2014 Installationsanleitung Netzwerklizenzen Vectorworks 2014 Beginnt Ihre Seriennummer mit einem G, lesen Sie hier weiter. Beginnt Ihre Seriennummer mit einem C, lesen Sie bitte auf Seite 4 weiter. Installation

Mehr

Administrative Tätigkeiten

Administrative Tätigkeiten Administrative Tätigkeiten Benutzer verwalten Mit der Benutzerverwaltung sind Sie in der Lage, Zuständigkeiten innerhalb eines Unternehmens gezielt abzubilden und den Zugang zu sensiblen Daten auf wenige

Mehr

Inhaltsverzeichnis. Teil 1 Node.js... 1

Inhaltsverzeichnis. Teil 1 Node.js... 1 xiii Teil 1 Node.js... 1 1 Was ist Node.js? 3 1.1 Die Zeitalter des Webs................................... 3 1.1.1 1990 bis 2000: Das Web 1.0....................... 3 1.1.2 2000 bis 2010: Das Web 2.0.......................

Mehr

Linux-Kernel- Programmierung

Linux-Kernel- Programmierung Michael Beck, Harald Böhme, Mirko Dziadzka, Ulrich Kunitz, Robert Magnus, Dirk Verworner Linux-Kernel- Programmierung Algorithmen und Strukturen der Version 1.0 ADDISON-WESLEY PUBLISHING COMPANY Bonn Paris

Mehr

Einführung Erste Schritte mit Mamut Online Survey

Einführung Erste Schritte mit Mamut Online Survey [Type text] Mamut Active Services Einführung Erste Schritte mit Mamut Online Survey 1 Erste Schritte mit Mamut Online Survey Inhalt Über Mamut Online Survey... 2 Erste Schritte mit Mamut Online Survey...

Mehr

Von Prozessen und Prozessoren (Prozess-Management)

Von Prozessen und Prozessoren (Prozess-Management) Von Prozessen und Prozessoren (Prozess-Management) V1.1 Technische Berufsschule Zürich IT Seite 1 Aus dem Geschichtsbuch: Grossrechner IBM 7094, 1965: Online- und Batchbetrieb IBM-Lochkarte Technische

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

CPU-Scheduling - Grundkonzepte

CPU-Scheduling - Grundkonzepte CPU-Scheduling - Grundkonzepte Sommersemester 2015 Seite 1 Gesamtüberblick 1. Einführung in Computersysteme 2. Entwicklung von Betriebssystemen 3. Architekturansätze 4. Interruptverarbeitung in Betriebssystemen

Mehr

Hylafax mit CAPI und Kernel 2.6 auf Debian Sarge

Hylafax mit CAPI und Kernel 2.6 auf Debian Sarge Hylafax mit CAPI und Kernel 2.6 auf Debian Lukas Mensinck First public release Version 1.0.0 Revision History Revision 1.0.0 2007.04.11 LukasMensinck Mensinck Consulting First public release of HowTo Type:

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

Installation und Dokumentation. juris Autologon 3.1

Installation und Dokumentation. juris Autologon 3.1 Installation und Dokumentation juris Autologon 3.1 Inhaltsverzeichnis: 1. Allgemeines 3 2. Installation Einzelplatz 3 3. Installation Netzwerk 3 3.1 Konfiguration Netzwerk 3 3.1.1 Die Autologon.ini 3 3.1.2

Mehr

Implementierung von Dateisystemen

Implementierung von Dateisystemen Implementierung von Dateisystemen Teil 2 Prof. Dr. Margarita Esponda WS 2011/2012 44 Effizienz und Leistungssteigerung Festplatten sind eine wichtige Komponente in jedem Rechnersystem und gleichzeitig

Mehr

Betriebssysteme Kap A: Grundlagen

Betriebssysteme Kap A: Grundlagen Betriebssysteme Kap A: Grundlagen 1 Betriebssystem Definition DIN 44300 Die Programme eines digitalen Rechensystems, die zusammen mit den Eigenschaften dieser Rechenanlage die Basis der möglichen Betriebsarten

Mehr

Lokales Storage Teil 1

Lokales Storage Teil 1 Lokales Storage Teil 1 Zinching Dang 08. Juli 2015 1 Lokales Storage im Allgemeinen Lokales Storage im Allgemeinen Datenträger, die direkt am Host angeschlossen sind Anbindung über verschiedene Bus-Systeme

Mehr

3 Firewall-Architekturen

3 Firewall-Architekturen Eine Firewall ist nicht ein einzelnes Gerät oder eine Gruppe von Geräten, sondern ein Konzept. Für die Implementierung eines Firewall-Konzepts haben sich in den vergangenen Jahren verschiedene Architekturen

Mehr

TeamViewer 9 Handbuch Wake-on-LAN

TeamViewer 9 Handbuch Wake-on-LAN TeamViewer 9 Handbuch Wake-on-LAN Rev 9.2-12/2013 TeamViewer GmbH Jahnstraße 30 D-73037 Göppingen www.teamviewer.com Inhaltsverzeichnis 1 Über Wake-on-LAN... 3 2 Voraussetzungen... 4 3 Windows einrichten...

Mehr

ChatServer. Unser Server

ChatServer. Unser Server ChatServer Wir wollen einen universell verwendbaren Server programmieren, der die wichtigsten Funktionen eines Chat-Servers erfüllt: es soll ein 'Threaded TCP Server' sein Clients können sich mit Port

Mehr