Rheinwerk Computing < openbook > Rheinwerk Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Vorwort
1 Einleitung
TEIL I: Einstieg in Linux
2 Die Installation
3 Erste Schritte
4 Linux als Workstation für Einsteiger
TEIL II: Grundlagen
5 Kernel
6 Grundlagen aus Anwendersicht
TEIL III: Die Shell
7 Die Shell
8 Reguläre Ausdrücke
9 Konsolentools
10 Die Editoren
11 Shellskriptprogrammierung mit der bash
12 Die C-Shell
TEIL IV: System- & Netzwerkadministration
13 Benutzerverwaltung
14 Grundlegende Verwaltungsaufgaben
15 Netzwerkgrundlagen
16 Anwendersoftware für das Netzwerk
17 Netzwerkdienste
18 Mailserver unter Linux
19 LAMP & Co.
20 DNS-Server
21 Secure Shell
TEIL V: Die grafische Oberfläche
22 Die grafische Oberfläche
23 Window-Manager und Desktops
24 X11-Programme
25 Multimedia und Spiele
TEIL VI: Systeminterna
26 Prozesse und IPC
27 Bootstrap und Shutdown
28 Dateisysteme
29 Virtualisierung und Emulatoren
TEIL VII: Programmierung und Sicherheit
30 Softwareentwicklung
31 Crashkurs in C und Perl
32 Einführung in Computersicherheit
33 Netzwerksicherheit überwachen
TEIL VIII: Anhang
A Lösungen zu den einzelnen Aufgaben
B Kommandoreferenz
C X11-InputDevices
D MBR
E Buch-DVDs
F Glossar
G Literatur
Stichwort
Ihre Meinung?

Spacer
Linux von Johannes Plötner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
Rheinwerk Computing
1282 S., 5., aktualisierte Auflage 2012, geb., mit 2 DVDs
49,90 Euro, ISBN 978-3-8362-1822-1
Pfeil 26 Prozesse und IPC
Pfeil 26.1 Prozessarten
Pfeil 26.1.1 Hintergrundprozesse
Pfeil 26.1.2 Dämonprozesse
Pfeil 26.2 Prozesse in der Shell
Pfeil 26.2.1 Wechseln zwischen Vorder- und Hintergrund
Pfeil 26.2.2 Jobs – behalten Sie sie im Auge
Pfeil 26.2.3 Hintergrundprozesse und Fehlermeldungen
Pfeil 26.2.4 Wann ist es denn endlich vorbei?
Pfeil 26.3 Prozesse und Signale
Pfeil 26.3.1 Das Syscall-Interface
Pfeil 26.3.2 Signale von der Kommandozeile senden: kill
Pfeil 26.3.3 Welche Signale gibt es?
Pfeil 26.3.4 Rechte
Pfeil 26.3.5 In der Praxis: Signale empfangen
Pfeil 26.4 Prozesse finden und beeinflussen
Pfeil 26.4.1 top und htop
Pfeil 26.4.2 ps und pstree
Pfeil 26.4.3 pgrep, pidof und pkill
Pfeil 26.5 Prozesse, Scheduling und Prioritäten
Pfeil 26.5.1 Das Scheduling
Pfeil 26.5.2 nice und renice
Pfeil 26.5.3 Echtzeit-Scheduling unter Linux
Pfeil 26.6 IPC im Detail
Pfeil 26.6.1 Pipes und FIFOs
Pfeil 26.6.2 Semaphore
Pfeil 26.6.3 Message Queues
Pfeil 26.6.4 Shared Memory
Pfeil 26.6.5 Unix-Domain-Sockets
Pfeil 26.7 Zusammenfassung
Pfeil 26.8 Aufgaben

Rheinwerk Computing - Zum Seitenanfang

26.5 Prozesse, Scheduling und PrioritätenZur nächsten Überschrift

In diesem Abschnitt wollen wir uns nun den Prioritäten von Prozessen und Threads widmen. Für einen normalen Desktop-PC ist dieses Thema zwar eher weniger wichtig, für kleine bis große Servermaschinen, Mainframes oder generell für Mehrbenutzersysteme können Prioritäten jedoch sehr wichtig werden.


Rheinwerk Computing - Zum Seitenanfang

26.5.1 Das SchedulingZur nächsten ÜberschriftZur vorigen Überschrift

Die meisten Menschen haben beim Thema »Prioritäten« etwas verquere Vorstellungen: Sie möchten am liebsten alles mit einer hohen Priorität versehen, um alles zu beschleunigen. Jedoch werden durch das Setzen von entsprechenden Zahlenwerten keine neuen Ressourcen geschaffen, es kann im Gegenteil nur über eine eventuelle Bevorzugung von einigen Prozessen entschieden werden.

Aus Kapitel 5, »Der Kernel«, dürfte Ihnen noch bekannt sein, dass der Scheduler den nächsten abzuarbeitenden Prozess auswählt. Prioritäten können diesen Prozess in gewisser Weise beeinflussen. Bevor wir nun auf die Details eingehen, möchten wir den Scheduling-Vorgang noch einmal hinsichtlich der Prioritäten erläutern.

Linux kennt drei verschiedene Scheduling Policies und unterscheidet statische und dynamische Prioritäten. Jedem Prozess ist dabei eine statische Priorität zugeordnet, die jedoch über Syscalls geändert werden kann.

Der Scheduler verwaltet für jede Priorität im Bereich von 0 bis 99 eine Liste – eine sogenannte Wait Queue oder auch Warteliste – mit lauffähigen Prozessen. Will der Scheduler nun den nächsten abzuarbeitenden Prozess heraussuchen, so wählt er den ersten Prozess aus der ersten nicht leeren Liste mit der höchsten Priorität. Die Scheduling Policy legt schließlich für jeden Prozess fest, wo er in der Liste seiner (statischen) Priorität wieder eingeordnet wird und wie er sich in der Liste bewegt.

SCHED_OTHER

Die normale Scheduling-Strategie ist dabei SCHED_OTHER. Sie gilt für alle Prozesse der statischen Priorität 0, die keine besonderen Erweiterungen für die Echtzeit benötigen. Dieses Scheduling nutzt das Zeitscheibenverfahren, bei dem jedem Prozess eine bestimmte Zeitdauer zugeteilt wird. Nach Ablauf dieser Zeitscheibe wird der aktuelle Prozess unterbrochen und ein anderer darf stattdessen arbeiten.

In diesem Zusammenhang wirken auch die dynamischen Prioritäten, auch Nice-Werte genannt. Diese Prioritäten können wieder über Syscalls (nämlich nice() beziehungsweise setpriority()) als Werte zwischen --20 und 20 vergeben werden, wobei --20 für die höchste zu vergebende Priorität steht.

Allerdings kann nur root seine Prozesse beschleunigen, indem er ihnen einen niedrigeren Nice-Wert als 0 zuordnet. Normale Benutzer können nur »nett« sein, also die Priorität ihrer Prozesse herabsetzen und damit weniger Ressourcen in Anspruch nehmen. Über diese dynamischen Prioritäten wird auch die Fairness des Schedulings geregelt: Wird nämlich bei der Auswahl des nächsten abzuarbeitenden Prozesses ein lauffähiger Prozess übergangen, so wird seine dynamische Priorität etwas erhöht, damit er beim nächsten Mal bessere Chancen hat.


Rheinwerk Computing - Zum Seitenanfang

26.5.2 nice und reniceZur nächsten ÜberschriftZur vorigen Überschrift

Bevor wir uns nun dem Echtzeit-Scheduling widmen, wollen wir zuerst das für den normalen Benutzer interessante Handling der Nice-Werte erläutern. Schließlich werden auf »normalen« Systemen die Echtzeitfähigkeiten in der Regel nicht genutzt.

Das Kommando »nice«

nice

Die Setzung der Nice-Werte erfolgt beim Start eines Programms in der Shell mit dem nice-Kommando. Das englische nice bedeutet so viel wie »nett«, und nett ist man ja, wenn man freiwillig auf Rechenzeit verzichtet. Dem Kommando wird die Priorität über den Parameter -n mitgeteilt, das eigentliche Kommando wird nachstehend mit allen Aufrufargumenten beschrieben:

Listing 26.26 Das Kommando »nice« in Aktion: Unser find-Prozess hat Zeit.

$ nice -n 19 find / -name libcurses.a >Ergebnis

Bereits laufende Prozesse

renice

Die dynamische Priorität bereits laufender Prozesse wird mit dem Kommando renice verändert. Dabei kann die Priorität mit dem Parameter -p über die Prozess-ID, mit dem Parameter -u über den Benutzernamen oder mit -g über die Benutzergruppe geändert werden.

Im folgenden Listing wird die Nice-Priorität des Prozesses mit der PID 491 um den Wert 10 verringert. Das Gleiche gilt für alle Prozesse des Benutzers »nobody«.

Listing 26.27 renice für Benutzer und PIDs

$ renice +10 -p 491 -u nobody

Rheinwerk Computing - Zum Seitenanfang

26.5.3 Echtzeit-Scheduling unter LinuxZur vorigen Überschrift

Die beiden Echtzeit-Strategien des Schedulings unter Linux (SCHED_FIFO und SCHED_RR) nutzen jeweils die statischen Prioritäten 1 bis 99. Ein entsprechender Prozess wird also, sofern er lauffähig ist, auch jeden anderen normalen Prozess verdrängen. [Fn. Das war schließlich die Semantik der unterschiedlichen Prioritäten, und »normale« SCHED_OTHER-Prozesse nutzen nun einmal nur die geringste statische Priorität.]

Prioritäten größer Null und damit alle Echtzeit-Features können nur von root beziehungsweise von dessen Prozessen genutzt werden.

SCHED_FIFO ist die einfachere der beiden Echtzeit-Strategien. Sie funktioniert wie folgt: Wenn ein solcher Prozess von einem Prozess mit einer höheren statischen Priorität verdrängt wird, bleibt er am Anfang seiner Liste und wird erst wieder ausgeführt, wenn alle Prozesse mit höherer Priorität beendet beziehungsweise geblockt sind.

Wird ein solcher Prozess – z. B. nach einem blockierenden Syscall – wieder lauffähig, so wird er am Ende der Liste mit allen Prozessen seiner Priorität einsortiert. Ein Aufruf der Syscalls sched_setscheduler() oder sched_setparam() wird den entsprechenden Prozess wieder an den Anfang der Warteliste befördern und so möglicherweise auch den aktuellen Prozess unterbrechen. Ein Aufruf von sched_yield() dagegen wird den Prozess wieder an das Ende der Liste setzen. Ein SCHED_FIFO-Prozess läuft also, bis er durch einen I/O-Request blockiert, durch einen höher priorisierten Prozess verdrängt oder durch einen Aufruf der Funktion sched_yield() dazu gebracht wird, freiwillig die Ressource Prozessor freizugeben.

SCHED_RR ist nun eine einfache Erweiterung von SCHED_FIFO: Hier gibt es zusätzlich eine begrenzte Zeitscheibe, die ein Prozess nutzen kann, bevor er wieder an das Ende seiner Warteliste gesetzt wird. Wird ein solcher Prozess von einem höher priorisierten Task unterbrochen, so verbleibt er am Anfang seiner Liste, um später den Rest seiner Zeitscheibe noch zu vollenden.

Egal welche Scheduling-Strategie oder -parameter man nun einsetzt, ein Kindprozess wird diese immer durch fork() erben. Wer aber nun wirklich entsprechende Applikationen entwickeln will, sollte einen Blick auf die Manpages von sched_setscheduler() und sched_setparam() werfen. Dort wird die Thematik noch einmal vertieft, und es wird auch erläutert, was alles schiefgehen kann. So wird beispielsweise empfohlen, bei der Entwicklung entsprechender Programme diese nur unter einer noch höher priorisierten Shell zu testen, da ansonsten bei einer Endlosschleife kein anderer Prozess mehr an die Reihe kommt und somit das ganze System hängt. [Fn. Also kann auch diese Gefahr als ein Grund dafür angesehen werden, dass nur root solche Prozesse starten darf.]

Man sollte bei diesem Thema jedoch immer beachten, dass Linux ein Mehrzwecksystem ist und nicht dafür entworfen wurde, harte Echtzeit-Anwendungen zu unterstützen. Bei diesen Anwendungen müssen Deadlines – also Zeitpunkte, bis zu denen eine Aufgabe ausgeführt werden muss – in jedem Fall eingehalten werden, ansonsten gibt es im schlimmsten Fall (etwa bei einer kritischen Zeitscheibe einer Reaktion des IT-Systems in einem Atomkraftwerk) eine Katastrophe.

Schließlich wurde Linux auf die durchschnittliche und nicht auf eine Worst-Case"=Performance hin optimiert. In diesem Sinne kann Linux höchstens »weiche« Echtzeit-Anforderungen erfüllen, also eine vorgegebene Deadline in der Regel einhalten, wie dies beispielsweise bei Multimedia-Anwendungen wünschenswert ist.

In der Regel ist das ja auch gerade das, was man will: Die durchschnittliche Antwortzeit auf Interrupts kann zum Beispiel auf Kosten der theoretisch maximal möglichen Zeit verkürzt werden. Wer jedoch wirklich harte Echtzeit-Anforderungen erfüllen muss, sollte einen Blick auf folgende Projekte werfen:

Alternativ gibt es auch Betriebssysteme wie QNX, die eigens für diesen Anwendungsbereich entwickelt wurden.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.

>> Zum Feedback-Formular
<< zurück
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux Handbuch






 Linux Handbuch


Zum Katalog: Linux Server






 Linux Server


Zum Katalog: Raspberry Pi






 Raspberry Pi


Zum Katalog: Ubuntu 14.04 LTS






 Ubuntu 14.04 LTS


Zum Katalog: Roboter bauen mit Arduino






 Roboter bauen
 mit Arduino


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Rheinwerk Verlag GmbH 2012
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de