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

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

Download:
- ZIP, ca. 15,7 MB
Buch bestellen
Ihre Meinung?

Spacer
 <<   zurück
Linux von Johannes Pl&ouml;tner, Steffen Wendzel
Das umfassende Handbuch
Buch: Linux

Linux
geb., mit 2 DVDs
1302 S., 39,90 Euro
Galileo Computing
ISBN 978-3-8362-1704-0
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 Die Rechte
    Pfeil 26.3.5 In der Praxis: Signale empfangen
  Pfeil 26.4 Prozesse finden und verarbeiten
    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


Galileo Computing - Zum Seitenanfang

26.5 Prozesse, Scheduling und Prioritäten  Zur nächsten ÜberschriftZur vorigen Überschrift

In diesem Abschnitt wollen wir uns nun den Prioritäten von Prozessen und Threads widmen. Für eine normale Workstation 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.


Galileo Computing - Zum Seitenanfang

26.5.1 Das Scheduling  Zur 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.

Abbildung Tux

Linux kennt drei verschiedene Scheduling Policies und unterscheidet statische und dynamische Prioritäten. Jedem Prozess ist dabei eine statische Priorität zugeordnet, die über Syscalls jedoch 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.


Galileo Computing - Zum Seitenanfang

26.5.2 nice und renice  Zur 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:

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

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

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«.

$ renice +10 -p 491 -u nobody

Listing 26.27  renice für Benutzer und PIDs


Galileo Computing - Zum Seitenanfang

26.5.3 Echtzeit-Scheduling unter Linux  topZur 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. [Das war schließlich die Semantik der unterschiedlichen Prioritäten, und »normale« SCHED_OTHER-Prozesse nutzen nun mal 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. [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.






 <<   zurück
  Zum Katalog
Zum Katalog: Linux, Ausgabe 2011






Linux, Ausgabe 2011
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Linux-Server






 Linux-Server


Zum Katalog: Linux Hochverfügbarkeit






 Linux Hoch-
 verfügbarkeit


Zum Katalog: LPIC-1






 LPIC-1


Zum Katalog: Debian GNU/Linux






 Debian GNU/Linux


Zum Katalog: openSUSE 11.2






 openSUSE 11.2


Zum Katalog: Shell-Programmierung






 Shell-Programmierung


Zum Katalog: Ubuntu GNU/Linux






 Ubuntu GNU/Linux


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2011
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.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de