Betriebssysteme - Prozesse

Betriebssysteme - Prozesse → alois.schuette@h-da.de 

Betriebssysteme - Prozesse 

→ alois.schuette@h-da.de 

Alois Schütte 

20. November 2013 

1 / 204


Inhaltsverzeichnis 

Ein Prozess kann als die Abstraktion eines Programms, das von einem 

Prozessor ausgeführt wird, angesehen werden. 

Hier wird behandelt, was Prozesse sind und wie sie in Betriebssystemen 

implementiert werden, inklusive Prozesskommunikation, -synchronisation 

und Scheduling. 

1 Prozessmodell 

2 Interprozesskommunikation 

3 IPC Probleme 

4 Scheduling 

2 / 204


Prozessmodell 

Prozessmodell 


Prozesszustände 

Implementierung von Prozessen 

Abstraktion des Prozessmodells in Java 



4 Scheduling 

3 / 204


Prozessmodell 

Prozessmodell 

Um zu verstehen, wie unterschiedliche Aktivitäten scheinbar gleichzeitig 

ablaufen, braucht man ein Modell eines sich in Ausführung befindenden 

Programms. 

Ein (sequentieller) Prozess ist ein sich in Ausführung befindendes 

(sequentielles) Programm zusammen mit: 

• dem aktuellen Wert des Programmzähler, 

• den Registerinhalten, 

• den Werten der Variablen und 

• dem Zustand der geöffneten Dateien und Netzverbindungen. 

Konzeptionell besitzt jeder Prozess seinen eigenen Prozessor - in der 

Praxis wird aber immer der reale Prozessor zwischen den Prozessen hinund 

hergeschaltet. 

4 / 204


Prozessmodell 

Sichtweisen 

Beim Mehrprogrammbetrieb mit 4 Programmen (A-D) ergeben sich 

damit folgende Sichtweisen: 

5 / 204


Prozessmodell 

Prozess-Hierarchie 

Ein Betriebssystem mit einen solchen Prozessmodell muss in der Lage 

sein, dass von einem (Initial-) Programm andere Prozesse erzeugt werden 

können. 

• In Unix dient dazu der fork-Systemaufruf. 

• Beim ” 

Hochfahren“ des Betriebssystems 

werden dann alle erforderlichen Prozesse 

erzeugt für Systemdienste, wie 

• Scheduler, 

• Dateidienst, 

• Terminaldienst, 

• ... 

6 / 204


Prozessmodell 

Prozesskategorien und Ausführungsmodi 

Damit das Betriebssystem allein die Ressourcen verwalten kann, werden 

die Prozesse in Kategorien unterteilt: 

• Kernel-Prozesse laufen von anderen Prozessen abgeschottet; sie 

sind privilegiert, direkt auf Ressourcen zuzugreifen. 

• User Prozesse verwenden stets Kernel-Funktionalität, um indirekt 

auf Ressourcen zuzugreifen. 

Heutige Prozessoren unterscheiden prinzipiell zwei Ausführungsmodi für 

Instruktionen: 

• privilegierten Modus (Kernel-Prozesse): 

z.B. E/A-Befehle, Registerzugriff und Interruptmaskierung 

• Normalmodus (User-Prozesse) 

Ein Userprozess ruft über Systemfunktionen (system calls) einen 

Dienst im eigenen Adressraum auf. 

Kein Prozess hat dabei direkten Zugriff auf den Speicher des Kerns. 

7 / 204


Prozessmodell 

Trap-Mechanismus 

Eine Kernel-Funktion wird stets über den 

Trap-Mechanismus (Kernel-Aufruf) aufgerufen: 

1 Speichern des Funktionskodes und der 

Parameter in ?speziellen Registern 

2 Auslösen eines Software Interrupts, d.h 

• Inkrementieren des Programmzählers 

• Umschalten in privilegierten Modus User 

Modus 

3 Ausführen der Kernelfunktion 

4 Speichern des Ergebnisses in Registern 

5 Umschalten in Normalmodus 

6 Zurückladen der Ergebnisse aus dem Register 

7 Ausführen der nächsten Instruktion der 

Anwendung 

1 

2 

3 

4 

5 

6 

7 

User- 

Modus 

Kernel- 

Modus 

User- 

Modus 

8 / 204


Prozessmodell 



Eine Aufgabe des Betriebssystems ist das Multiplexen des physischen 

Prozessors. 

Diese Aufgabe übernimmt der Scheduler zusammen mit dem 

Dispatcher. 

Prozesse können sich in verschiedenen Zustände befinden. 

1 rechnend (running) 

der Prozessor ist dem Prozess zugeteilt 

2 bereit (ready) 

der Prozess ist ausführbar, aber ein anderer Prozess ist gerade 

rechnend 

3 blockiert (waiting) 

der Prozess kann nicht ausgeführt werden, da er auf ein externes 

Ereignis wartet (z.B. Benutzer hat Taste auf Tastatur gedrückt) 

Diese Zuständen bilden eine Entscheidungsgrundlage für die Auswahl 

eines geeigneten Kandidaten bei einem Prozesswechsel. 

9 / 204


Prozessmodell 


Zustandsübergänge 

1 Prozess wartet auf externes 

Ereignis 

2 Scheduler wählt anderen 

Prozess aus, da die Zeitscheibe 

des Prozesses abgelaufen ist 

3 Scheduler wählt diesen Prozess 

aus 

4 externes Ereignis ist eingetreten 

5 ein neuer Prozess wird erzeugt 

6 der Prozess terminiert 

6 

rechnend 

1 2 

3 

blockiert 

bereit 

4 

5 

Die Zustandsübergänge werden vom Dispatcher durchgeführt, die 

Auswahl eines rechenbereiten Prozesses übernimmt der Scheduler. 

10 / 204


Prozessmodell 


Modell für Prozesssystem 

Damit ergibt sich ein Modell für ein Prozesssystem, bei dem 

• die unterste Schicht die Unterbrechungen behandelt und das 

Scheduling der Prozesse inklusive Erzeugung und Abbrechen von 

Prozessen erledigt; 

• alle anderen Prozesse befinden sich auf gleicher Ebene darüber und 

haben einen sequentiellen Kontrollfluss. 

• Somit gibt es stets einen Wechsel von Aktivitäten eines 

(User-)Prozesses und des Kerns. 

Prozesse 

1 2 3 ... n 

User-Modus 

Kernel-Modus 

Dispatcher / Scheduler 

11 / 204


Prozessmodell 



Das o.g. Prozessmodell kann in einem Betriebssystem durch eine 

Prozesstabelle, die für jeden Prozess einen Eintrag enthält, realisiert 

werden. 

Ein Eintrag muss alle Informationen enthalten, um einen Prozess wieder 

anlaufen zu lassen, wenn er suspendiert wurde: 

• Zustand, 

• Programmzähler, 

• Stack-Zeiger, 

• belegten Speicher, 

• Zustand der geöffneten Dateien und 

• Verwaltungsinformationen (bisher belegte CPU Zeit, 

Schedulinginformationen, etc.) 

Welche Information muss auf Ebene des HAL bei Wechsel des 

HAL-Programms/Prozesses gespeichert werden? Also was muss 

passieren, wenn ein HAL-Prozessor einen Prozesswechsel durchführt? 

12 / 204


Prozessmodell 


Prozesstabelle 

Je nach Betriebssystem variieren diese Felder der Prozesstabelle. 

$ ps -o "%p %r %c %a %x %t" 

PID PGID COMMAND COMMAND TIME 

3427 3427 bash -bash 00:00:00 

3496 3496 ps ps -o %p %r %c % 00:00:00 

$ 

Ein Prozesswechsel kann durch ein externes Ereignis ausgelöst werden. 

Dazu wird jeder Klasse von E/A-Geräten (Festplatten, Terminals, etc.) 

ein Unterbrechungsvektor zugeordnet, der die Adresse einer 

Unterbrechungsbehandlungsprozedur (Interrupt Routine) enthält. 

Wenn z.B. ein Terminal eine Unterbrechung auslöst, dann wird 

hardwareseitig (Microcode) folgendes getan: 

1 Programmzähler des aktuell laufender Prozess und einiger Register 

auf Stack legen 

2 Aufruf der entsprechenden Unterbrechungsbehandlungsprozedur 

Alle anderen Aktivitäten (Auswahl des nächsten Prozesses, der nach der 

Unterbrechungsroutine laufen soll) muss durch die Betriebssystemsoftware 

erfolgen. 

13 / 204


Prozessmodell 


Dämonen 

In Unix werden Verwaltungsaufgaben von speziellen Programmen, die als 

Hintergrundprozesse ablaufen, übernommen. 

Beispiele sind: 

cron Systemcronometer 

at Ausführen eines Kommandos zu einer vorgegebenen Zeit 

inetd Internet Service Dämon 

sshd Secure Shell Dämon 

Solche Prozesse werden oft beim Hochfahren des Betriebssystems 

gestartet und erst beim Shutdown des Systems beendet. 

Auf Shellebene kann man sich Dämonen ansehen durch das 

ps-Kommando. Sie sind daran zu erkennen, dass die Spalte ” 

TTY“ ein 

Fragezeichen ” 

?“ enthält. 

$ ps -el | grep \? 

1277 ? 00:02:22 crond 

1291 ? 00:00:00 atd 

1578 ? 00:00:03 sshd 

30045 ? 00:03:41 sendmail 

14 / 204


Prozessmodell 


Diese Prozesse sind als Dämonen realisiert: 

• Jeder Prozess (außer init) in Unix hat einen Vater und gehört zu 

einer Prozessgruppe. 

• Jede Prozessgruppe hat einen Prozess als Prozessgruppenleiter 

und besitzt maximal ein Kontrollterminal. Das Kontrollterminal 

liefert für alle Mitglieder der Prozessgruppe die Standardeinstellungen 

von stdin, stdout und stderr. Das Kontrollterminal 

lässt sich immer unter dem Namen ” 

/dev/tty“ ansprechen. 

• Ein Signal des Kontrollterminals wird an alle Mitglieder der 

Prozessgruppe gesendet (die Shell schützt sich und alle von ihr 

initiierten Prozesse allerdings davor). 

• Prozesse, die zwar Mitglieder einer Prozessgruppe sind, aber kein 

Kontrollterminal haben, nennt man Dämonen. 

• Da sie kein Kontrollterminal besitzen, sind sie nicht über 

Signale abzubrechen. 

• Diese Dämonen treiben ihr Unwesen ” 

im Bauch der Maschine“. 

15 / 204


Prozessmodell 


Zur Implementierung von Dämonen sollen folgende Regeln eingehalten 

werden: 

• Zunächst sollte ein fork ausgeführt werden, der Elternprozess sollte 

danach ein exit ausführen. Dadurch wird folgendes erreicht: 

1 Wird der Prozess von der Shell gestartet, so denkt die Shell, der 

Prozess wäre terminiert, da der Vater beendet ist. 

2 Das Kind erbt vom Vater die Prozessgruppe, bekommt aber (durch 

fork) eine neue PID. Dadurch ist ausgeschlossen, dass der Prozess 

ein Prozessgruppenführer ist. 

• Der nächste Schritt ist, den Systemaufruf ” 

setsid()“ auszuführen. 

Dadurch wird eine neue Session erzeugt und der Aufrufer wird 

Prozessgruppenführer. 

• Nun wird in das aktuelle Verzeichnis gesetzt. Es sollte das 

Root-Verzeichnis sein, damit nicht ein eventuelle gemountetes 

Dateisystem (wenn das das Home-Verzeichnis des Aufrufers war) 

dazu führt, dass das Betriebssystem nicht heruntergefahren werden 

kann. 

• Die Maske zum Dateierzeugen (umask) wird auf 0 gesetzt, damit 

nicht geerbte Maske vom Aufrufer dazu führt, dass der Dämon 

Dateien nicht anlegen kann. 

• Letztlich sollten alle nicht benötigten Filedeskriptoren geschlossen 16 / 204


Prozessmodell 


Beispiel Dämon 

daemon.c 

1 # include 

2 # include 

3 # include 

4 int daemon_init ( void ) { 

5 pid_t pid ; 

6 if (( pid = fork ()) < 0) 

7 return ( -1); 

8 else if ( pid != 0) 

9 exit (0); /* parent goes bye - bye */ 

10 /* child */ 

11 setsid (); /* become session leader */ 

12 chdir ("/"); /* change working directory */ 

13 umask (0); /* clear our file mode creatio mask */ 

14 return (0); 

15 } 

16 int main () { /* ... * some initial tasks */ 

17 daemon_init (); /* make a daemon out of the program */ 

18 sleep (100); /* daemon code , we see the 

19 daemon with ps -x */ 

20 exit (0); 

21 } 

17 / 204


Prozessmodell 


Dämonen 

$ ./ daemon 

$ ps -xl 

F UID PID PPID PRI WCHAN STAT TTY TIME COMMAND 

0 500 22873 22871 20 wait Ss pts /0 0:00 -bash 

1 500 23030 1 20 hrtime Ss ? 0:00 ./ daemon ← 

0 500 23031 22873 20 R+ pts /0 0:00 ps -xl 

$ 

Nach de Start des Dämon kann man mit ” 

ps –xl“ sehen, dass der Dämon 

aktiv ist und als Vater und den Prozess 1 besitzt. 

Ein Problem bei Dämonen ist, dass es nicht möglich ist, stderr und 

stdout zu verwenden. Also muss man eine Methode entwickeln, wie ein 

Dämon die Aktivitäten protokollieren kann. In Unix existiert das syslog 

Werkzeug, um Nachrichten geordnet zu verarbeiten. 

18 / 204


Prozessmodell 


Zombies 

Ein Prozess terminiert und hört auf zu existieren, wenn zwei Ereignisse 

eingetreten sind: 

1 Der Prozess hat sich selbst beendet oder wurde durch ein Signal 

beendet und 

2 der Vaterprozess hat ” 

wait()“ aufgerufen. 

Ein Prozess, der beendet wird, bevor der Vater einen wait-Aufruf für ihn 

ausgeführt hat, erhält einen besonderen Zustand, er wird ein Zombie: 

• Der Prozess wird vom Scheduler nicht mehr berücksichtigt, er wird 

aber nicht aus der Prozesstabelle entfernt. 

• Wenn der Vater dann einen wait-Aufruf veranlasst, wird der Prozess 

aus der Prozesstabelle entfernt und der belegte (Haupt-) Speicher 

wird frei gegeben. 

ps -l: 

0 laufend 

S schlafend (sleeping) 

R auf den Prozessor wartend (runable) ... 

Z Zombie 

19 / 204


Prozessmodell 


Beispiel Zombie 

zombie.c 

1 /* Create zombie to illustrate "ps -el */ 

2 # include 

3 int main () { 

4 int pid ; 

5 if (( pid = fork ()) == -1) 

6 fprintf ( stderr ," fork failed !\n"); 

7 if ( pid == 0) { /* Child */ 

8 printf (" child : %d\n", getpid ()); 

9 exit (1); /* because father will not wait , a zombie is born */ 

10 } else { /* fahter */ 

11 printf (" father : %d\n", getpid ()); 

12 sleep (30); 

13 /* now you can use ps -el to see during 30 secs that 

14 child is a zombie */ 

15 exit (0); 

16 } 

17 } 

20 / 204


Prozessmodell 


Beispiel Zombie 

$ ./ zombie & 

[1] 23036 

$ father : 23036 

child : 23037 

ps -l 

F S PID PPID WCHAN TTY TIME CMD 

0 S 22873 22871 wait pts /0 00:00:00 bash 

0 S 23036 22873 hrtime pts /0 00:00:00 zombie ← 

1 Z 23037 23036 exit pts /0 00:00:00 zombie ← 

0 R 23038 22873 - pts /0 00:00:00 ps 

$ 

21 / 204


Prozessmodell 


Zombies entfernen per SIGCHLD 

Wenn ein Vater nicht auf die Beendigung seiner Kinder warten kann (z.B. 

bei der Shell mit Hintergrundprozessen), kann man die Zombies 

eliminieren, indem 

• der Vater auf das Signal SIGCHLD reagiert 

• die Signalbehandlungsroutine dann mittels waitpid den Zobmiestatus 

des Kindes aufhebt. 

zombie cleanup.c 

/* Simplest dead child cleanup in a SIGCHLD handler . 

* Prevent zombie processes but don 't actually do anything 

* with the information that a child died . 

*/ 

# include 

... 

/* SIGCHLD handler . */ 

static void sigchld_hdl ( int sig ) { 

/* Wait for all dead processes . 

* We use a non - blocking call to be sure this signal handler 

* will not block if a child was cleaned up in another 

* part of the program . 

*/ 

while ( waitpid (-1, NULL , WNOHANG ) > 0) ; ← 

} 

22 / 204


Prozessmodell 


Zombies entfernen per SIGCHLD 

int main ( int argc , char * argv []) { 

int i; 

if ( signal ( SIGCHLD , sigchld_hdl )) { ← 

perror (" signal "); 

return 1; 

} 

} 

/* Make some children . */ 

for (i = 0; i < 5; i ++) { 

switch ( fork ()) { 

case -1: 

perror (" fork "); 

return 1; 

case 0: // do something 

return 0; 

} 

} 

while (1) { 

// father performs something 

} 

return 0; 

23 / 204


Prozessmodell 



Um Eigenschaften und Probleme mit Prozessen zeigen zu können, werden 

Algorithmen in der Vorlesung in Java (oder C) beschrieben. 

Betrachtet werden Java-Threads als Abstraktion von Prozessen eines 

Rechners: 

Java Prozess 

Threads 

Rechner 

Prozesse 

gemeinsamer 

Speicher 

Speicher 

Deshalb wird hier zunächst gezeigt, wie in Java Threads erzeugt werden 

können. 

24 / 204


Prozessmodell 


Erzeugen und Starten vonJava-Threads 

Beim Start eines Java Programms wird ein Prozess erzeugt, der einen 

Thread enthält, der die Methode main der angegebenen Klasse ausführt. 

Der Code weiterer Threads muss in einer Methode mit Namen run 

realisiert werden. 

public void run () { 

// Code wird in eigenem Thread ausgeführt 

} 

Ein Programm, das Threads erzeugt, erbt von der Klasse Thread und 

überschreibt die Methode run() (auf Interfaces wird später eingegangen): 

25 / 204


Prozessmodell 


Hello World 

MyThread.java 

1 public class MyThread extends Thread { ← 

2 public void run () { 

3 System . out . println (" Hello World "); 

4 } 

6 public static void main ( String [] args ) { 

7 MyThread t = new MyThread (); ← 

8 t. start (); ← 

9 } 

10 } 

Die Methode start() ist in der Klasse thread definiert und startet den 

Thread, genauer die Methode run(). Somit wird zunächst ein Thread 

erzeugt (new ...), dann durch start die Methode run aufgerufen und 

somit ” 

Hello World“ ausgegeben. 

26 / 204


Prozessmodell 


mehrere Threads 

Werden mehrere Thread erzeugt, so ist die Ausführungsreihenfolge nicht 

vorhersehbar! 

Loop1.java 

1 public class Loop1 extends Thread { 

2 private String myName ; 

3 public Loop1 ( String name ) { 

4 myName = name ; 

5 } 


8 for ( int i = 1; i


Prozessmodell 


Threads in komplexen Klassenhierarchien 

Wenn sich die Methode run() in einer Klasse befinden soll, die selbst 

bereits aus einer anderen Klasse abgeleitet ist, so kann diese Klasse nicht 

zusätzlich von Thread abgeleitet werden (Java unterstützt keine 

Mehrfachvererbung). 

In diesem Fall kann das Interface Runnable des Package java.lang 

verwendet werden. 

MyRunnableThread.java 

1 public class MyRunnableThread implements Runnable { ← 


3 System . out . println (" Hello World "); 

4 } 


6 MyRunnableThread runner = new MyRunnableThread (); ← 

7 Thread t = new Thread ( runner ); ← 

8 t. start (); 

9 } 

10 } 

28 / 204


Prozessmodell 


Threadtermination 

Ein Thread terminiert, wenn seine run()-Methode (bzw. die Methode 

main() im Fall des Ursprungs-Thread) beendet ist. 

Sind alle von einem Prozess initiierten Threads beendet, so terminiert der 

Prozess (falls es kein Dämon ist). 

Die Klasse Thread stellt eine Methode isAlive bereit, mit der abfragbar 

ist, ob ein Thread noch lebt (schon gestartet und noch nicht terminiert 

ist). 

Damit könnte aktives Warten etwa wie folgt programmiert werden: 

1 // MyThread sei aus Thread abgeleitet 

2 MyThread t = new myThread (); 


4 while (t. isAlive ()) 

5 ; 

6 // hier ist jetzt : t. isAlive == false , der Thread t ist terminiert 

Man sollte es so aber nie tun, da aktives Warten sehr rechenintensiv ist. 

wieso? 

29 / 204


Prozessmodell 


Warten bis Thread beendet ist 

Wenn in einer Anwendung auf das Ende eines Thread gewartet werden 

muss, etwa um die Rechenergebnisse des Thread weiterzuverarbeiten, 

kann die Methode join der Klasse Thread benutzt werden. 

Der Thread wird blockiert, bis der Thread, auf den man wartet, beendet 

ist. 

1 // MyThread sei aus Thread abgeleitet 

2 MyThread t = new myThread (); 


4 t. join (); // blockiert , bis t beendet ist . 

5 // auch hier jetzt : t. isAlive == false , der Thread t ist terminiert 

wieso ist das besser? 

30 / 204


Prozessmodell 


Verwendung von join zum Abfragen von Ergebnissen 

Das folgende Beispiel verwendet Threads, um ein grosses Feld von 

Boolean zu analysieren, indem mehrere Threads parallel arbeiten, wobei 

je Thread ein Bereich des Feldes bearbeitet wird. 

1 0 0 0 1 0 1 1 0 0 0 0 1 1 1 1 

T1:1 T2:3 T3:0 T4:4 

main: 8 

31 / 204


Prozessmodell 


1 class Service implements Runnable { ← 

2 private boolean [] array ; 

3 private int start ; 

4 private int end ; 

5 private int result ; 

7 public Service ( boolean [] array , int start , int end ) { 

8 this . array = array ; 

9 this . start = start ; 

10 this . end = end ; 

11 } 

13 public int getResult () { 

14 return result ; 

15 } 

17 public void run () { ← 

18 for ( int i = start ; i


Prozessmodell 


1 public class AsynchRequest { 

2 private static final int ARRAY_SIZE = 100000; ← 

3 private static final int NUMBER_OF_SERVERS = 100; ← 


6 // start time 

7 long startTime = System . currentTimeMillis (); 

9 // array creation , init with random boolean values ← 

10 boolean [] array = new boolean [ ARRAY_SIZE ]; 

11 for ( int i = 0; i < ARRAY_SIZE ; i ++) { 

12 if( Math . random () < 0.1) 

13 array [i] = true ; 

14 else 

15 array [i] = false ; 

16 } 

18 // creation of array for service objects and threads ← 

19 Service [] service = new Service [ NUMBER_OF_SERVERS ]; ← 

20 Thread [] serverThread = new Thread [ NUMBER_OF_SERVERS ]; ← 

22 int start = 0; 

23 int end ; 

24 int howMany = ARRAY_SIZE / NUMBER_OF_SERVERS ; 

33 / 204


Prozessmodell 


1 // creation of services and threads ← 

2 for ( int i = 0; i < NUMBER_OF_SERVERS ; i ++) { 

3 end = start + howMany - 1; 

4 service [i] = new Service ( array , start , end ); ← 

5 serverThread [i] = new Thread ( service [i ]); ← 

6 serverThread [i]. start (); // start thread i ← 

7 start = end + 1; 

8 } 

10 // wait for termination of each service ( thread ) ← 

11 try { 

12 for ( int i = 0; i < NUMBER_OF_SERVERS ; i ++) 

13 serverThread [i]. join (); ← 

14 } catch ( InterruptedException e) {} 

16 // accumulate service results ← 

17 int result = 0; 

18 for ( int i = 0; i < NUMBER_OF_SERVERS ; i ++) { 

19 result += service [i]. getResult (); ← 

20 } 

34 / 204


Prozessmodell 


1 // end time 

2 long endTime = System . currentTimeMillis (); 

3 float time = ( endTime - startTime ) / 1000.0 f; 

4 System . out . println (" computation time : " + time ); 

6 // print result 

7 System . out . println (" result : " + result ); 

8 } // main 

9 } 

$ java AsynchRequest 

Rechenzeit : 0.11 

Ergebnis : 9953 

$ 

35 / 204


Prozessmodell 


zum Üben für zu Hause 

1 Testen des Verhaltens, wenn NUMBER OF SERVERS mit 1, 10, 

100, 1.000, 10.000 und 100.00 gesetzt wird und Erklärung des 

Ergebnisses. 

2 Ändern der Metode run() und Test und Erklärung der Auswirkung 

gegenüber dem Verhalten von 1. 


for ( int i = start ; i


Prozessmodell 


Beenden von Threads per Programm 

Die Klasse Thread besitzt die Methode stopp(), zum Abbruch von 

Threads. 

Die Verwendung ist aber problematisch, da ein inkonsistenter Zustand 

erreicht werden kann. 

• Dies ist der Fall, wenn der Thread gerade eine 

synchronized()-Methode (später) ausführt und den Zustand eines 

Objektes verändert und dies aber nicht bis zum Schluss durchführen 

kann (wegen Stopp()). 

• Durch Stopp werden alle Sperren aufgehoben, der Thread konnte 

aber nicht fertig werden. 

Eine Abhandlung zum Stoppen von Threads kann nachgelesen werden in 

threadPrimitiveDeprecation oder HowToStopThreads. 

Wir werden später nochmals darauf zurückkommen. 

37 / 204


Interprozesskommunikation 




Probleme des gemeinsamen Zugriffs 

Kritischer Bereich 

Lösungsansätze in Java 

Semaphore 

Monitore und andere Primitive 

Nachrichtenaustausch 


4 Scheduling 

38 / 204




Betriebssysteme stellen unterschiedliche Mechanismen zur Verfügung, mit 

denen zwei Prozesse kommunizieren können: 

• beide Prozesse können sich den Arbeitsspeicher teilen, oder 

• gemeinsamer Speicher ist nicht verfügbar, es werden externe Medien, 

wie Dateien verwendet, auf die gemeinsam zugegriffen werden kann. 

Die Probleme sind aber unabhängig davon, welcher der beiden 

Mechanismen verwendet wird. Im folgenden werden die Probleme und 

Lösungen für den Zugriff auf gemeinsam verwendete Ressourcen gezeigt. 

39 / 204





Wenn mehrere Threads in Java gemeinsam auf Daten zugreifen, müssen 

sich die einzelnen Threads ” 

verständigen“, wer wann was machen darf. 

Dazu werden die Möglichkeiten, die Java bietet, am Beispiel von 

Buchungen eines Bankkontos gezeigt. 

Eine Bank wird modelliert durch 4 Klassen: 

Die Klasse Konto repräsentiert ein Konto mit dem Attribut kontostand 

und den Methoden zum setzen und abfragen des aktuellen Kontostandes. 

BankOperation.java 

1 class Konto { 

2 private float kontostand ; 

3 public void setzen ( float betrag ) { 

4 kontostand = betrag ; 

5 } 

6 public float abfragen () { 

7 return kontostand ; 

8 } 

9 } 

40 / 204




Bank 

Die Klasse Bank hat als Attribut ein Feld von Referenzen auf 

Konto-Objekte (Konten). Die Methode buchen implementiert einen 

Buchungsvorgang auf ein Konto. 

1 class Bank { 

2 private Konto [] konten ; 

4 public Bank () { 

5 konten = new Konto [100]; 

6 for ( int i = 0; i < konten . length ; i ++) { 

7 konten [i] = new Konto (); 

8 } 

10 public void buchen ( int kontonr , float betrag ) { 

11 float alterStand = konten [ kontonr ]. abfragen (); 

12 float neuerStand = alterStand + betrag ; 

13 konten [ kontonr ]. setzen ( neuerStand ); 

14 } 

15 } 

41 / 204




Bankangestellte 

Die Klasse Bankangestellte ist aus der Klasse Thread abgeleitet. Der 

Name der Angestellten wird der Name des Thread, da mehrere 

Bankangestellte (Threads) für die Bank arbeiten können sollen. 

Buchungen werden in der run-Methode durch Zufallszahlen erzeugt. 

1 class BankAngestellte extends Thread { 

2 private Bank bank ; 

3 public BankAngestellte ( String name , Bank bank ) { 

4 super ( name ); this . bank = bank ; 

5 start (); 

6 } 


9 for ( int i = 0; i < 10000; i ++) { 

10 /* Kontonummer einlesen ; simuliert durch Wahl einer 

11 Zufallszahl zwischen 0 und 99 */ 

12 int kontonr = ( int )( Math . random ()*100); 

13 /* Überweisungsbetrag einlesen ; simuliert durch Wahl einer 

14 Zufallszahl zwischen -500 und +499 */ 

15 float betrag = ( int )( Math . random ()*1000) - 500; 

16 bank . buchen ( kontonr , betrag ); 

17 } 

18 } 

19 } 

42 / 204




Bankbetrieb 

In der Klasse Bankbetrieb wird eine Bank mit 2 Bankangestellten 

simuliert. 

Die Bankangestellten fangen an zu Arbeiten, wenn die Objekte erzeugt 

werden (durch new und dann die Methode start im Konstruktor von 

Bankangestellte). 

1 public class Bankbetrieb { 


3 Bank sparkasse = new Bank (); 

4 BankAngestellte müller = 

5 new BankAngestellte (" Andrea Müller ", sparkasse ); ← 

6 BankAngestellte schmitt = 

7 new BankAngestellte (" Petra Schmitt ", sparkasse ); ← 

8 } 

9 } 

sparkasse ist das gemeinsam verwendete Objekt ! 

43 / 204




verlorene Buchungen 

Bei dieser Bank können aber Buchungen verloren gehen! 

→ am Rechner 

Jede der 2 Bankangestellten bebucht das 

• Konto 1 

• jeweils 1000 mal mit 

• jeweils 1 EUR 

Also muss das Konto 1 am Ende des Tages einen Kontostand von 2000 

EUR aufweisen ! 

Dieses Problem tritt immer auf, wenn mehrere Threads auf ein 

gemeinsam nutzbares Objekt (hier das Feld Konto der Klasse Bank) 

zugreifen und es keine Schutzmechanismen gibt. 

44 / 204




Verdeutlichung 

Gehen wir von folgender Situation aus: 

• Andrea Müller bucht -100 EUR auf Konto 47, es sollen also 100 

EUR abgebucht werden. Der Kontostand sein 0. 

• Petra Schmitt führt auch Buchungen für Konto 47 aus, es sollen 

1000 EUR gutgeschrieben werden. 

Thread Andrea Müller: 

1 public void buchen ( int kontonr =47 , float betrag = -100) { Konten[47]=0 

2 float alterStand = konten [ kontonr ]. abfragen (); alterStand=0 

3 -> Umschalten auf Thread Petra Schmitt 



6 } 

Thread Petra Schmitt: 

1 public void buchen ( int kontonr =47 , float betrag =1000) { Konten[47]=0 


3 float neuerStand = alterStand + betrag ; neuerStand=1000 

4 konten [ kontonr ]. setzen ( neuerStand ); Konten[47]=1000 

5 } 

6 -> Umschalten auf Thread Andrea Müller 45 / 204




Verdeutlichung 

Thread Andrea Müller: 

1 public void buchen ( int kontonr =47 , float betrag = -100) { Konten[47]=0 


3 -> Weiter nach Unterbrechung 

4 float neuerStand = alterStand + betrag ; neuerStand=-100 

5 konten [ kontonr ]. setzen ( neuerStand ); Konten[47]=-100 

6 } 

Nun ist die Gutschrift, die Petra Schmitt gebucht hat verloren! Der 

aktuelle Kontostand ist -100 anstatt +900. 

Die Ursache des Problems ist, dass eine Buchung aus mehreren 

Java Anweisungen besteht und zwischen diesen Anweisungen 

zwischen Threads umgeschaltet werden kann. 

46 / 204





Das gezeigte Problem der verlorenen Buchungen kann auch abstrakt 

formuliert werden. 

Der Teil eines Programms, in dem auf gemeinsame Ressourcen 

zugegriffen wird, wird kritischer Bereich genannt. 

Zeitkritische Abläufe (wie das Buchen des selben Kontos) 

können vermieden werden, wenn sich zu keinem Zeitpunkt zwei 

Prozesse in ihrem kritischen Bereich befinden. 

Im folgenden werden Lösungsversuche (nicht korrekte) diskutiert. 

47 / 204




Lösungsversuch 1 (nur eine Anweisung) 

In der Klasse Bank wird das Buchen durch eine Java Anweisung realisiert: 

1 class Konto { 

2 private float kontostand ; 

3 public void buchen ( float betrag ) { 

4 kontostand += betrag ; ← nur eine Anweisung 

5 } also kein Umschalten möglich 

6 } 







15 } 


18 konten [ kontonr ]. buchen ( betrag ); ← 

19 } 

20 } 

Wie beurteilen Sie den Ansatz ? 

48 / 204




Lösungsversuch 1 

Dies ist keine Lösung, denn Java-Programme werden in Bytekode 

übersetzt. 

Dabei wird aus der einer Java-Anweisung 

1 kontostand += betrag ; 

schematisch etwa folgender Code: 

1 LOAD ( kontostand ); 

2 ADD ( betrag ); 

3 STORE ( kontostand ); 

Die JVM führt also 3 Anweisungen aus, wobei dann auch wieder 

dazwischen umgeschaltet werden kann. 

49 / 204




Lösungsversuch 2 (Sperrvariable) 

Die Idee ist die Verwendung von Sperrvariablen: 

• Zu einem Zeitpunkt darf nur eine Angestellte eine Buchung 

ausführen. 

• Erst wenn die Buchung abgeschlossen ist, darf eine andere 

Angestellte buchen. 

Dies ist offensichtlich eine korrekte Lösung: der kritische Bereich wird zu 

einem Zeitpunkt nur einmal betreten. 

Ein Implementierungsversuch ist: Alle Klassen entsprechen den des 

Ausgangsbeispiels; nur die Klasse Bank wird wie folgt geändert. 

50 / 204






3 private boolean gesperrt ; ← 





9 } 

10 gesperrt = false ; ← 

11 } 


14 while ( gesperrt ); ← 

15 gesperrt = true ; ← 




19 gesperrt = false ; ← 

20 } 

21 } 

Die 3 Anweisungen zum Buchen können nur ausgeführt werden, falls die 

Bank momentan nicht gesperrt ist. Ist die Bank gesperrt, wartet der 

Thread, bis sie durch den sperrenden Thread wieder entsperrt wird. 

51 / 204




Diese Realisierung ist auf den ersten Blick korrekt; es gibt aber folgende 

Probleme: 

1 Paralleles Arbeiten wird unmöglich: parallel könnten 

unterschiedlichen Konten bebucht werden – dies ist hier 

ausgeschlossen. 

2 Durch das aktive Warten (while (gesperrt) ;) wird kostbare 

Rechenzeit aufgewendet, um nichts zu tun. 

3 Die Realisierung ist nicht korrekt. Das aktive Warten ist keine 

unteilbare Aktion, denn der Bytekode sieht etwa wie folgt aus: 

while ( gesperrt ); 1: LOAD ( gesperrt ); 

2: JUMPTRUE 1; 

gesperrt = true ; 3: LOADNUM ( TRUE ); 

4: STORE ( geperrt ) 

Wenn hierbei zwischen Befehl 1 und 2 umgeschaltet wird und die 

Sperre frei ist (geperrt=false) so kann ein wartender Thread buchen. 

Um eine korrekte Lösung in Java zu programmieren, sind in Java 

Sprachelemente zur Synchronisation verfügbar. 

52 / 204





Die erste korrekte (aber ineffiziente) Lösung für die Probleme 2 (aktives 

Warten) und 3 (verlorene Buchungen) nutzt die Möglichkeit von Java, 

Methoden als synchronized zu kennzeichnen. 

Dazu wird einfach die Klasse buchen mit dem Attribut synchronized 

versehen – ansonsten ändert sich nichts. 







8 } 

10 public synchronized void buchen ( int kontonr , float betrag ) { 




14 } 

15 } 

53 / 204




synchronized 

Die Java-Superklasse Object beinhaltet als Eigenschaft eine Sperre. Da 

jede Klasse von Object abgeleitet ist, besitzen alle Klassen diese 

Eigenschaft. 

Das Sperren gehorcht dem ” 

acquire-release Protokoll“: 

Die Sperre wird gesetzt (acquire), beim Betreten einer 

synchronized-Methode (oder synchronized Blocks) und entfernt 

(release) bei Verlassen des Blocks (auch bei Verlassen durch 

einee Exception). 

54 / 204




acquire release Protokoll 

• Wird eine Methode einer Klasse mit 

synchronized gekennzeichnet, so muss diese 

Sperre zuerst gesetzt werden, bevor die 

Methode ausgeführt wird, hier versucht von 

Thread B. 

• Hat ein anderer Thread A die Sperre bereits 

gesetzt (seine Methode ist in Ausführung), so 

wird der aufrufende Thread B blockiert. 

• Das Blockieren ist aber nicht durch aktives 

Warten realisiert, sondern der Thread B wird 

beim Thread-Umschalten nicht mehr 

berücksichtigt. 

• Wenn die Methode des Thread A beendet ist, 

wird die Sperre entfernt und der Thread B 

wird wieder beim Scheduling wieder 

berücksichtigt. 

Tread A 

Sperre 

Object 

Thread B 

55 / 204




Somit ist das Problem 2 und 3 gelöst. Diese Lösung ist aber ineffizient 

(Problem 1), da die ganze Bank gesperrt wird, obwohl doch nur 

Probleme auftauchen, wenn auf das selbe Konto gebucht wird. 

Dies wird im Beispielprogramm umgesetzt,indem die Java-Eigenschaft, 

Blöcke als synchronized zu kennzeichnen, verwendet wird. 


2 ... 


5 synchronized(konten[kontonr]) { 




9 } 

10 } 

11 } 

Ein Block (...) wird dabei mit dem Schlüsselwort synchronized versehen 

und das Objekt, auf das sich die Sperre bezieht wird danach angegeben. 

56 / 204




Verwendung von synchronized 

Wenn alle Threads nur lesend auf ein Objekt zugreifen, ist keine 

Synchronisation erforderlich – hier würde durch synchronized ein 

unnötiger Rechenaufwand erzeugt werden (Setzen und Lösen der Sperre). 

Generell gilt folgende Regel: 

Wenn von mehreren Threads auf ein Objekt zugegriffen 

wird, wobei mindestens ein Thread den Zustand 

(repräsentiert durch die Werte der Attribute) des Objekts 

ändert, dann müssen alle Methoden, die auf den Zustand 

lesend oder schreibend zugreifen, mit synchronized 

gekennzeichnet werden. 

57 / 204




Petrinetz für synchronized 

Betrachten wir folgendes Beispiel, ein Programm, bei dem alle Threads 

auf demselben Objekt arbeiten: 

1 class K { 

2 public synchronized void m1 () { action1 (); } 

3 public synchronized void m2 () { action2 (); } 

4 private void action1 () { ... } 

5 private void action2 () { ... } 

6 } 

8 class T extends Thread { 

9 private K einK ; 

10 public T(K k) { 

11 einK = k; 

12 } 


14 while (...) { 

15 switch (...) { 

16 case ...: einK .m1 (); break ; 

17 case ...: einK .m2 (); break ; 

18 } 

19 } 

20 } 

21 } 

→ petrinet 

58 / 204




Petrinetz für synchronized 

• Die Stellen des Petri-Netzes entsprechen den 

Stellen zwischen den Anweisungen im 

Programmtext. 

• Die Transitionen sind die Anweisungen und die 

Marken sind die Threads bzw. die Sperre des 

gemeinsam benutzten K-Objektes, die durch 

synchronized belegt wird. 

• Zum Start eines Thread muss sowohl eine 

Marke auf ” 

start“ als auch auf ” 

lock“ liegen. 

• Schaltet eine Transition, so wird die Marke 

von lock“ entfernt und erst wieder auf sie 

” 

gelegt, wenn die synchronized Methode 

syncEnd“ erreicht hat. 

” 

• Damit kann zu einem Zeitpunkt höchstens ein 

Thread eine der synchronized Methoden auf 

ein Objekt anwenden. 

59 / 204




Test, ob eine Sperre gesetzt ist 

Der Test, ob eine Sperre gesetzt ist, ist durch holdsLock möglich: 

Main.java 

1 public class Main { 

2 public static void main ( String [] argv ) throws Exception { 

3 Object o = new Object (); 

5 System . out . println ( Thread . holdsLock (o )); ← 

6 synchronized (o) { 

7 System . out . println ( Thread . holdsLock (o )); ← 

8 } 

9 } 

10 } 

60 / 204




Hörsaalübung 

Welche Ausgabe erzeugt das Programm? Test.java 

1 class Even { 

2 private int n = 0; 

3 public int next () { // POST : next is always even ← 

4 ++n; 

5 try { Thread . sleep (( long )( Math . random ()*10)); 

6 } catch ( InterruptedException e) { } 

7 ++n; 

8 return n; 

9 } 

10 } 

11 public class Test extends Thread { 

12 private Even e; 

13 public Test ( Even e) { this .e = e;} 


15 for ( int i = 1 ; i




→ Hörsaalübung 

Welche Ausgabe erzeugt das Programm? Test1.java 


2 ... 

3 } 

4 public class Test1 extends Thread { 

5 private Even e; 

6 public Test1 ( Even e) { 

7 this .e = e; 

8 } 


10 for ( int i = 1 ; i




wait und notify 

Werden Objekte von mehreren Threads benutzt und dabei deren 

Zustände verändert, dann gewährleisten synchronized-Methoden, dass ein 

Thread immer einen konsistenten Zustand eines Objektes vorfindet. 

In vielen Anwendungssituationen ist es erforderlich, dass eine Methode 

nur dann ausgeführt wird, 

• wenn zusätzlich zum konsistenten Zustand 

• weitere anwendungsspezifische Bedingungen erfüllt sind. 

63 / 204




Beispiel Parkhaus 

Ein Parkhaus wird modelliert, indem der Zustand durch die aktuell noch 

freie Parkplätze beschrieben wird und Autos durch Threads mit 

Methoden Einfahren (enter()) und Ausfahren (leave()) realisiert sind. 

• Beim Einfahren vermindert sich die Anzahl der freien Plätze um 1; 

beim Ausfahren eines Autos wird sie um 1 erhöht. 

• Die freien Plätze können nicht erhöht werden, wenn das Parkhaus 

voll ist (freie Plätze == 0). 

• Da ein Parkhaus von mehreren Autos (Threads) benutzt wird und 

der Zustand (=freie Plätze) durch ein Auto verändert wird, müssen 

die Methoden enter() und leave() synchronized sein. 

Zunächst werden zwei vergebliche Versuche, das Problem ” 

freie Plätze“ 

zu lösen gezeigt, dann eine korrekte Implementierung. 

64 / 204




unkorrekter Versuch 

ParkingGarageOperation.java 

1 class ParkingGarage { 

2 private int places ; 

3 public ParkingGarage ( int places ) { 

4 if ( places < 0) places = 0; this . places = places ; 

5 } 

6 public synchronized void enter () { // enter parking garage 

7 while ( places == 0) ; ← actives Warten 

8 places - -; 

9 } 

10 public synchronized void leave () { // leave parking garage 

11 places ++; 

12 } 

13 } 

Diese Lösung hat zwei Probleme: 

1 Aktives Warten führt zu schlechter Performance. 

65 / 204










5 } 



8 places - -; 

9 } 


11 places ++; 

12 } 

13 } 



2 Die Lösung arbeitet nicht korrekt, wenn ein Parkhaus einmal voll 

geworden ist. Wenn ein Auto in ein volles Parkhaus einfahren will (Aufruf 

Methode enter), dann kann das Parkhaus nicht mehr benutzt werden, weil 

der Thread wegen synchronized und der while-Schleife die Sperre nie mehr 

freigibt, da kein anderes Auto ausfahren kann (wegen der Sperre). 

65 / 204










5 } 



8 places - -; 

9 } 


11 places ++; 

12 } 

13 } 



2 Die Lösung arbeitet nicht korrekt, wenn ein Parkhaus einmal voll 

geworden ist. Wenn ein Auto in ein volles Parkhaus einfahren will (Aufruf 

Methode enter), dann kann das Parkhaus nicht mehr benutzt werden, weil 

der Thread wegen synchronized und der while-Schleife die Sperre nie mehr 

freigibt, da kein anderes Auto ausfahren kann (wegen der Sperre). 

65 / 204




Korrekte Lösung ohne aktives Warten 

Das aktive Warten auf einen freien Platz ist weder im gesperrten Zustand 

des Parkhaus-Objektes noch im nicht gesperrten Zustand korrekt. 

Durch die Methoden wait() und notify() der Klasse Objekt kann das 

Problem gelöst werden. 

public class Object { 

... 

public final void wait () throws InterruptedException {...} 

public final void notify () { ...} 

} 

Diese beiden Methoden müssen auf ein Objekt angewendet werden, das 

durch synchronized gesperrt ist, ansonsten tritt die Ausnahme 

” IllegalMonitorStateException“ auf. 66 / 204




wait, notify, notifyAll 

Ein wait bewirkt die folgenden Aktionen: 

1 Der laufende Thread blockiert. 

2 Wenn der laufende Thread unterbrochen wurde, wird die Ausnahme 

InterruptedException erzeugt. 

3 Die JVM fügt den laufenden Thread in eine Menge (wait set) ein, 

die mit dem Objekt assoziiert ist. 

4 Der synchronization Lock für das Objekt wird freigegeben (released), 

alle anderen Locks bleiben erhalten. 

67 / 204





Ein notify bewirkt die folgenden Aktionen: 

1 Ein zufälliger Thread t wird aus dem Waitingset des Objektes 

ausgewählt. 

2 t muss den Lock des Objektes wieder erhalten, d.h. Er blockiert 

solange, bis der Thread der notify aufgerufen hat, den Lock besitzt 

oder bis ein anderer Thread, der den Lock hält, ihn freigegeben hat. 

3 t wird nach erhalten des Lock nach seinem wait weitermachen. 

Ein notifyAll arbeitet genauso, nur dass alle Threads im Waitingset 

ausgewählt werden (Achtung: nur einer kann aber weitermachen, da die 

anderen ja auf den Erhalt des Lock warten. sind. 

68 / 204





69 / 204





70 / 204





71 / 204





72 / 204





73 / 204




Parkhaus mit korrekter Lösung 





5 if ( places < 0) 

6 places = 0; 

7 this . places = places ; 

8 } 


11 while ( places == 0) { 

12 try { 

13 wait (); ← 


15 } 

16 places - -; 

17 } 


20 places ++; 

21 notify (); ← 

22 } 

23 } 

74 / 204





1 class Car extends Thread { 

2 private ParkingGarage parkingGarage ; 

4 public Car ( String name , ParkingGarage p) { 

5 super ( name ); 

6 this . parkingGarage = p; 

7 start (); 

8 } 


11 while ( true ) { 

12 try { 

13 sleep (( int )( Math . random () * 10000)); // drive before parking 


15 parkingGarage . enter (); 

16 System . out . println ( getName ()+ ": entered "); 

17 try { 

18 sleep (( int )( Math . random () * 20000)); // stay into the garage 


20 parkingGarage . leave (); 

21 System . out . println ( getName ()+ ": left "); 

22 } 

23 } 

24 } 

75 / 204





1 public class ParkingGarageOperation { 

2 public static void main ( String [] args ){ 

3 ParkingGarage parkingGarage = new ParkingGarage (10); 

4 for ( int i =1; i




Frage 


2 ... 


5 while ( places == 0) { ← if anstelle von while 

6 try { 

7 wait (); 


9 } 

10 places - -; 

11 } 


14 places ++; 

15 notify (); } 

16 } 

Was passiert, wenn man in der Methode enter(), die while-Schleife durch 

ein if ersetzt? 

Die Lösung müsste immer noch korrekt sein, da der Thread doch erst 

geweckt wird, wenn ein Platz frei wurde und somit kann er in das 

Parkhaus einfahren. Ist die Argumentation korrekt? 

77 / 204




Antwort 

Nein, denn obwohl er geweckt wird, wenn ein Platz frei geworden ist, 

heißt das ja nicht, dass er auch vom Scheduler ausgewählt wird. Es 

könnte ein anderer Thread, der gerade einfahren will ausgewählt werden, 

der dann den freien Platz belegt. 

Dies entspricht in der Realität dem Tatbestand, dass ein Auto vor dem 

Einlass steht und von einem anderen dahinter stehenden Wartenden 

überholt wird, der dann in die letzte Parklücke einfährt. 

78 / 204




Modellierung von wait- und notify durch Petri-Netze 

class K { 

public synchronized void m1 () { 

while (...) 

wait (); ← 

action1 (); } 


action2 (); 

notify (); ← 

} 

private void action1 () { ... } 


} 

class T extends Thread { 

private K einK ; 

public T(K k) { 

einK = k; 

} 


while (...) 

switch (...) { 

case ...: einK .m1 (); break ; 


} 

} 

} 

79 / 204




Die Stelle checkCond1“ entspricht der Überprüfung der Wartebedingung. Der 

” 

Aufruf von wait() wird durch die Transition wait1“ modelliert. Die Anzahl der 

” 

Marken in der Stelle waiting1“ entspricht der Anzahl der wartenden Threads. 

” 

Das Schalten der Transition wait1“ bewirkt, dass eine Marke auf die Stelle 

” 

lock“ gelegt wird, dies entspricht der Freigabe der Sperre beim Aufruf von 

” 

wait() – dadurch können weitere Threads die Methode m1“ aufrufen. 

” 

Irgendwann wird ein Thread die Methode m2“ aufrufen. Dann wird nach 

” 

Schalten der Transition action2“ eine Marke auf der Stelle afterAction2“ 

” ” 

liegen. Nun folgt notify(): die Transition notify2“ kann auf jeden Fall schalten. 

” 

Falls sich mindestens eine Marke in der Stelle waiting1“ befindet, kann 

” 

zusätzlich die Transition wakeup1“ schalten. Dadurch entsteht zwischen 

” 

” wakeup1“ und notify2“ ein Konflikt. Durch Zuweisen einer höheren Priorität 

” 

an wakeup1“ erreicht man, dass nur die Transition wackup1“ schaltet. Die 

” ” 

Transition notify2“ soll nämlich nur Schal- ten, wenn sich keine Marke auf 

” 

waiting1“ befindet (dies ist die Semantik non notify(): notify() weckt genau 

” 

einen Thread, wenn es einen solchen gibt; ansonsten ist notify() wirkungslos). 

80 / 204




wait() und notifyAll() 

Probleme mit wait() und notify() entstehen, wenn mehrere Threads in 

der Warteschlange stehen und der falsche Thread geweckt wird. 

Dies wird am Erzeuger-Verbraucher Problem demonstriert. 

• Ein Erzeuger (producer) will Werte an 

einen Verbraucher (consumer) senden. 

• Erzeuger und Verbraucher sind Threads. 

• Die Werte, die ausgetauscht werden, sind 

in einem Puffer (implementiert durch 

Integervariable) abgelegt, auf die beide 

Threads Zugriff haben. 

• Der Erzeuger verwendet die Methode 

put(), um einen Wert in den Puffer zu 

schreiben; 

• der Verbraucher kann einen Wert aus dem 

Puffer durch die Methode get() lesen. 

81 / 204




Erzeuger-Verbraucher Problem 

• Bei der Realisierung darf es nicht 

vorkommen, dass ein Wert verloren geht, 

etwa weil der Erzeuger einen neuen Wert 

in den Puffer schreibt, bevor der 

Verbraucher den alten Wert gelesen hat. 

• Weiterhin darf ein Wert nicht mehrmals 

gelesen werden, etwa wenn der 

Verbraucher erneut liest, bevor der 

Erzeuger einen neuen Wert geschrieben 

hat. 

• Diese Problematik soll durch Warten 

realisiert werden: 

• der Erzeuger wartet mit dem Schreiben, 

bis der Verbraucher den Wert gelesen 

hat; 

• der Verbraucher wartet, bis ein neuer 

Wert in den Puffer geschrieben ist. 

82 / 204




Unkorrekte Lösung 

Der Puffer wird durch die Klasse Buffer mit 

• den Attributen 

• data (Werte) und 

• available (Flag zeigt an, ob Daten bereit stehen) und den 

• Methoden 

• put() und 

• get() 

realisiert. 

83 / 204




1 class Buffer { 

2 private boolean available = false ; 

3 private int data ; 

5 public synchronized void put ( int x) { 

6 while ( available ) { 

7 try { 

8 wait (); ← 


10 } 

11 data = x; 

12 available = true ; 

13 notify (); ← 

14 } 

16 public synchronized int get () { 

17 while (! available ) { 

18 try { 

19 wait (); ← 


21 } 

22 available = false ; 

23 notify (); ← 

24 return data ; 

25 } 

26 } 

84 / 204




Erzeuger und Verbraucher werden als Threads modelliert, wobei im 

Konstruktor eine Referenz auf das gemeinsam benutzte Objekt (buffer) 

übergeben wird. 

Der Erzeuger produziert 100 Werte, der Verbraucher konsumiert 100 

Werte. 

1 class Producer extends Thread { 

2 private Buffer buffer ; 

3 private int start ; 

5 public Producer ( Buffer b, int s) { 

6 buffer = b; 

7 start = s; 

8 } 


11 for ( int i = start ; i < start + 100; i ++) { 

12 buffer . put (i); 

13 } 

14 } 

15 } 

85 / 204




1 class Consumer extends Thread { 

2 private Buffer buffer ; 

4 public Consumer ( Buffer b) { 

5 buffer = b; 

6 } 


9 for ( int i = 0; i < 100; i ++) { 

10 int x = buffer . get (); 

11 System . out . println (" got " + x); 

12 } 

13 } 

14 } 

86 / 204




In der Klasse ProduceConsume werden ein Puffer, ein Erzeuger und ein 

Verbraucher erzeugt und die beiden Threads gestartet. 

1 public class ProduceConsume { 


3 Buffer b = new Buffer (); 

4 Consumer c = new Consumer (b); 

5 Producer p = new Producer (b, 1); 

6 c. start (); 

7 p. start (); 

8 } 

9 } 

Ein Aufruf des Programms bewirkt also: 

$ java ProduceConsume 

got 1 

got 2 

got 3 

got 4 

got 5 

... 

got 100 

$ 

87 / 204




Normalerweise hat man die Situation, dass mehrere Erzeuger und 

mehrere Verbraucher parallel arbeiten: 

ProduceConsume2.java 

1 public class ProduceConsume2 { 


3 Buffer b = new Buffer (); 

4 Consumer c1 = new Consumer (b); 



7 Producer p1 = new Producer (b, 1); 



10 c1. start (); 

11 c2. start (); 

12 c3. start (); 

13 p1. start (); 

14 p2. start (); 

15 p3. start (); 

16 } 

17 } 

88 / 204




Ein Lauf des Programms kann folgende Ausgabe bewirken (das hängt 

von Betriebssystem und Java-Version ab): 

$ java ProduceConsume2 

got 1 

got 101 

got 2 

got 102 

got 103 

got 201 

got 3 

got 104 

got 202 

... 

got 230 

got 231 

got 33 

got 8 

got 232 

D.h. das Programm bleibt stehen, es passiert nichts mehr; es wird keine 

neue Ausgabe mehr erzeugt, das Programm ist aber noch nicht beendet. 

Dieses Verhalten wurde verursacht, da durch notify() der ” 

falsche“ 

Thread geweckt wurde. 

89 / 204




Erklärung 

1 Alle Verbraucher c1, c2 und c3 können laufen. Da der Puffer 

anfänglich leer ist, werden alle 3 Threads durch wait() innerhalb 

get() blockiert und in die Warteschlange des Objektes b 

aufgenommen. 

2 Nun startet der Thread p1, der eine Wert in den Puffer b ablegt und 

einen Verbraucher weckt, nehmen wir an c1. Nun hat die 

Warteschlange und der Puffer folgendes Aussehen: 

90 / 204




Erklärung 

3 p1 läuft weiter und will einen Wert in den Puffer schreiben. Da der 

Puffer voll ist, blockiert er und wird in die Warteschlange eingereiht: 

4 Nehmen wir an, es wird auf den Erzeuger p2 umgeschaltet. Da der 

Puffer immer noch voll ist, wird auch p2 blockiert. Dies wiederholt 

sich für p3: Warteschlange für Objekt b 

91 / 204




Erklärung 

5 Der einzige Thread, auf den nun noch umgeschaltet werden kann, ist 

der vorher geweckte Thread c1. Der nimmt nun einen Wert aus dem 

Puffer. Dann wird einer der Threads in der Warteschlange 

geweckt, gehen wir von c2 aus. 

6 c1 arbeitet weiter und will einen Wert aus dem Puffer nehmen; der 

Puffer ist leer, also wird c1 blockiert und es steht noch immer kein 

Wert im Puffer: 

92 / 204




Erklärung 

7 Der Thread, auf den als einziges umgeschaltet werden kann, ist der 

Verbraucher c2. Er versucht einen Wert zu lesen, der Puffer ist 

leer, also blockiert er: 

Da nun alle Thread in der Warteschlange sind, kann keiner weiter 

arbeiten, das Programm steht. 

Schritt 5 hat außerdem gezeigt : der Verbraucher c1 hat einen 

anderen Verbraucher (c2) geweckt. Dies war der ” 

falsche“ Thread. 

Die Lösung des Problems kann nun darin bestehen, dass nicht ein 

Thread, sondern alle Thread geweckt werden. Da nur einer ausgewählt 

wird und jeder in einer while-Schleife prüft, ob er arbeiten kann, wird das 

funktionieren. 

93 / 204




Korrekte Lösung durch wait-notifyAll 

Die Klasse Objekt besitzt neben dem einfachen notify(), eine weitere 

Methode zum Aufwecken von Threads: notifyAll() weckt alle in der 

Warteschlange eines Objekts befindlichen Threads. 

Die korrekte Lösung besteht also darin, notify() durch notifyAll() zu 

ersetzen: ProduceConsume3.java 

1 class Buffer { ... 


3 while ( available ) { 

4 try { wait ();} catch ( InterruptedException e) {} 

5 } 

6 data = x; 

7 available = true ; 

8 notifyAll (); ← 

9 } 


11 while (! available ) { 

12 try { wait ();} catch ( InterruptedException e) {} 

13 } 

14 available = false ; 

15 notifyAll (); ← 

16 return data ; 

17 } 

18 } 

94 / 204




Regel für notifyAll 

Prinzipiell kann man immer notify() durch notifyAll() ersetzen, die 

Umkehrung allerdings wäre falsch (wie im letzten Beispiel gesehen). 

Die Methode notifyAll() ist zu verwenden, wenn mindestens eine der 

beiden folgenden Situationen zutrifft: 

1 In der Warteschlange befinden sich Threads, mit unterschiedlichen 

Wartebedingungen (z.B. Puffer leer, Puffer voll). Dann kann bei 

Verwendung von notify() der ” 

falsche“ Thread geweckt werden. 

2 Durch die Veränderung des Zustands eines Objekts können mehrere 

Threads weiterlaufen (Wert im Puffer - alle wartenden Verbraucher 

können arbeiten). 

95 / 204




Modellierung von wait- und notifyAll durch Petri-Netze 

class K { 


while (...) 

wait (); 

← 

action1 (); } 


action2 (); 

notifyAll (); ← 

} 



} 

class T extends Thread { 

private K einK ; 

public T(K k) { 

einK = k; 

} 


while (...) 

switch (...) { 



} 

} 

} 

96 / 204



Semaphore 

Semaphore 

1965 wurde von Dijkstra das Konzept der Semaphore zur Synchronisation 

vorgeschlagen. 

• Eine Semaphore ist eine Integervariable, deren 

• Wert Null anzeigt, dass kein Prozess (Thread) mehr zu wecken ist, 

• ein Wert grösser Null bedeutet, dass Wecksignale zu 

berücksichtigen sind. 

• Als Operationen wurde definiert ” 

DOWN“ (=p) und ” 

UP“ (=v). 

• ” 

Down“ prüft, ob der Semaphore größer als Null ist, dann wird der 

Wert vermindert; ist der Wert Null, wird der Thread schlafen gelegt 

und die DOWN-Operation ist beendet. 

• ” 

UP“ inkrementiert den Semaphore. 

Sowohl ” 

UP“ als auch ” 

DOWN“ sind dabei atomare Operationen, 

d.h. es ist sichergestellt, dass während der Ausführung der 

Operration kein anderer Thread auf den Semaphore zugreifen kann. 

97 / 204



Semaphore 

Semaphore Implementierung in Java 

Semaphore.java 

public class Semaphore { 

private int value ; 

public Semaphore ( int init ) { ← 

if( init < 0) 

init = 0; 

value = init ; 

} 

public synchronized void p() { ← Dijkstra’s operation p=down 

while ( value == 0) { 

try { wait (); } ← 

catch ( InterruptedException e) {} 

} 

value - -; 

} 

} 

public synchronized void v() { ← Dijkstra’s operation v=up 

value ++; 

notify (); 

← 

} 

98 / 204



Semaphore 

Gegenseitiger Ausschluss mit Semaphoren 

Gegenseitiger Ausschluss bezeichnet eine Situation, in der ein bestimmtes 

Programmstück zu einer Zeit von höchstens einem Thread 

ausgeführt werden darf. 

• In Java kann dazu eine synchronized Methode verwendet werden: 

auf ein Objekt kann dadurch zu einem Zeitpunkt nur von einem 

Thread zugegriffen werden. 

• Hier soll nun nicht mit synchronized gearbeitet werden, sondern es 

wird eine Klasse mit einer Semaphore verwendet. 

Als kritischen Abschnitt bezeichnet man das Programmstück, das von 

höchstens einem Thread betreten werden darf. 

99 / 204



Semaphore 

Gegenseitiger Ausschluss mit Semaphoren 

Im folgenden Beispiel werden die Aktionen, die ein Thread im kritischen 

Abschnitt ausführt simuliert durch eine Sleep-Operation. In einer realen 

Anwendung würde hier das Codefragment stehen, das auf die 

gemeinsamen Objekte zugreift. 

Der kritische Abschnitt wird durch Semaphore geschützt, indem 

1 vor Betreten die Semaphor-Methode down(), 

2 danach die Methode up() 

aufgerufen wird. 

100 / 204



Semaphore 

MutualExclusion.java 

1 class MutexThread extends Thread { 

2 private Semaphore mutex ; 

4 public MutexThread ( Semaphore mutex , String name ) { 

5 super ( name ); 

6 this . mutex = mutex ; 

7 start (); 

8 } 



12 mutex .p (); ← 

13 System . out . println (" kritischen Abschnitt betreten : " 

14 + getName ()); 

15 try { sleep (( int )( Math . random () * 100));} 

16 catch ( InterruptedException e) {} 

17 mutex .v (); ← 

18 System . out . println (" kritischen Abschnitt verlassen : " 

19 + getName ()); 

20 } 

21 } 

22 } 

101 / 204



Semaphore 

MutualExclusion.java 

1 public class MutualExclusion { 


3 int noThreadsInCriticalSection =1; 

4 if ( args . length != 1) { 

5 System . err . println ( 

6 " usage : java MutualExclusion < NoThreadsInCriticalSection >"); 

7 System . exit (1); 

8 } else 

9 noThreadsInCriticalSection = Integer . parseInt ( args [0]); 

10 Semaphore mutex = new Semaphore ( noThreadsInCriticalSection ); 

11 for ( int i = 1; i



Semaphore 

Der Aufruf zeigt, dass stets nur so viele Threads im kritischen Abschnitt 

sind, wie man beim Aufruf angegeben hat: 

1 $ java MutualExclusion 1 

2 kritischen Abschnitt betreten : Thread 1 ← 1 

3 kritischen Abschnitt verlassen : Thread 1 ← 0 







10 ... 

11 $ java MutualExclusion 3 










21 ... 

103 / 204



Semaphore 

Frage 

Was passiert durch Aufruf von 

$ java MutualExclusion 0 

104 / 204



Semaphore 


Ändern Sie das letzte Programm (EvenThread) so ab, dass die Klasse 

Even ohne synchronized- Methoden auskommt. 

Verwenden Sie dazu Semaphore. Test.java 


2 private int n = 0; 

3 public int next () { // POST : next is always even ← 

4 ++n; 

5 try { Thread . sleep (( long )( Math . random ()*10)); 


7 ++n; 

8 return n; 

9 } 

10 } 

105 / 204



Semaphore 

Bearbeitungsreihenfolge von Threads festlegen 

In vielen Anwendungen ist es erforderlich, dass Threads parallel arbeiten 

und dennoch eine Abarbeitungsreihenfolge einzuhalten ist. Dabei starten 

alle Threads gleichzeitig, führen gewisse Aktionen aus und müssen dann 

warten, bis andere Threads Aktivitäten abgeschlossen haben. 

Insgesamt lassen sich solche Abhängigkeiten durch einen Graphen 

darstellen: 

1 Knoten sind Threads, 

2 eine Kante existiert von einem Thread T1 zu T2, falls T1 seine 

Aktivitäten beendet haben muss, bevor T2 starten kann. 

Das folgende Beispiel demonstriert eine solche Situation. 

106 / 204



Semaphore 

Die Umsetzung in Java erfolgt durch Semaphore: 

• Für jede Abhängigkeit (Kante im Graph) wird 

eine Semaphore verwendet. Die Semaphoren 

sind in einem Array sems zusammengefasst, so 

dass die nebenstehend gezeigten 

Abhängigkeiten definiert sind. 

• Bevor eine Aktion ausgeführt wird, wird die 

p()-Methode für alle Semaphoren, die den 

eingehenden Kanten entsprechen, ausgeführt; 

• nach der Aktion die v()-Methode auf allen 

Semaphoren der ausgehenden Kanten. 

• Der Einfachheit halber bekommen alle 

Threads eine Referenz auf das 

Semaphoren-Array, auch wenn nicht alle 

Threads jede Semaphore benutzen. 

107 / 204



Semaphore 

Aus Sicht des Threads i werden folgende Aktionen ausgeführt: 

1 i führt p()-Operation aus: Warten auf v-Operation von i-1 

2 i-1 hat v()-Operation ausgeführt: i kann Aktion ausführen 

3 i führt v-Operation aus: i+1 kann aktiv werden 

108 / 204



Semaphore 

TimingRelation.java 

1 class T1 extends Thread { 

2 private Semaphore [] sems ; 

4 public T1( Semaphore [] sems ) { 

5 this . sems = sems ; 

6 start (); 

7 } 

9 private void a1 () { 

10 System . out . println ("a1"); 

11 try { 

12 sleep (( int )( Math . random () * 10)); 


14 } 


17 a1 (); 

18 sems [0]. v (); 

19 sems [1]. v (); 

20 sems [2]. v (); 

21 } 

22 } 

109 / 204



Semaphore 






6 start (); 

7 } 



11 try { 



14 } 


17 sems [0]. p (); ← 

18 a2 (); 

19 sems [3]. v (); ← 

20 } 

21 } 

110 / 204



Semaphore 






6 start (); 

7 } 



11 try { 



14 } 


17 sems [1]. p (); 

18 a3 (); 

19 sems [4]. v (); 

20 } 

21 } 

111 / 204



Semaphore 






6 start (); 

7 } 



11 try { 



14 } 


17 sems [2]. p (); 

18 a4 (); 

19 sems [5]. v (); 

20 } 

21 } 

112 / 204



Semaphore 






6 start (); 

7 } 



11 try { 



14 } 


17 sems [3]. p (); 

18 sems [4]. p (); 

19 sems [5]. p (); 

20 a5 (); 

21 } 

22 } 

113 / 204



Semaphore 


1 public class TimingRelation { 


3 Semaphore [] sems = new Semaphore [6]; 

4 for ( int i = 0; i < 6; i ++) { 

5 sems [i] = new Semaphore (0); 

6 } 

7 new T4( sems ); 





12 } 

13 } 

$ java TimingRelation 

a1 

a3 

a2 

a4 

a5 

$ java TimingRelation 

a1 

a2 

a3 

a4 

a5 

$ 

114 / 204



Semaphore 

Additive Semaphoren 

Semaphoren sind Integerwerte, wobei die p()- und v()-Operationen den 

Integerwert jeweils um eins inkrementieren bzw. dekrementieren. 

Eine Verallgemeinerung davon stellen additive Semaphore dar: 

der Integer kann um beliebige Werte inkrementiert bzw. 

dekrementiert werden. 

115 / 204



Semaphore 

Die Methoden p() und v() haben ein Integerargument, das angibt, um 

welchen Wert erniedrigt bzw. erhöht werden soll. 

Dieses Argument muss positiv sein, ansonsten könnte z.B. eine p- 

Operation die Semaphore erhöhen. 

AdditiveSemaphore.java 

1 public class AdditiveSemaphore { 

2 private int value ; 

4 public synchronized void p( int x) { 

5 if(x



Semaphore 

AdditiveSemaphore.java 

1 public synchronized void v( int x) { 

2 if(x 0) 

10 v(x); 

11 else if(x < 0) 

12 p(-x); 

13 } 

Die Methode v(int) muss notifyAll() verwenden. Würde notify() 

verwendet werden, könnten u.U. mehrere Threads weiterlaufen. 

117 / 204



Semaphore 

Der Programmcode zeigt, dass eine additive Semaphore ” 

auf einen 

Schlag“ erhöht oder erniedrigt wird. 

Dies bedeutet, dass die Verwendung von einer p-Operation p(n) nicht 

identisch ist mit n p-Operationen p(1): 

• Nehmen wir an, zwei Threads verwenden eine additive Semaphore 

zur Synchronisation; der aktuelle Wert sei 4. Beide wollen den Wert 

um 3 erniedrigen. 

• richtige Vorgehensweise: 

• T1 und T2 führen p(3) aus. 

• T1 wird ausgewählt und p(3) ist abgeschlossen. T2 blockiert beim 

Aufruf P(3). 

• falsche Vorgehensweise: 

• T1 und T2 führen jeweils p(1); p(1); p(1); aus. 

• T1 wird ausgewählt und (p(1); p(1);) ist abgeschlossen (Semaphor 

== 2), dann wird auf T2 umgeschaltet. 

• T2 führt (p(1); p(1);) nun blockiert beim Aufruf p(1); 

• T1 blockiert beim Aufruf p(1) → Verklemmung 

118 / 204



Semaphore 

Semaphorgruppen 

Eine Semaphorgruppe ist eine Verallgemeinerung einer additiven 

Semaphore: 

• Ein Aufruf der Methode change() erhöht oder erniedrigt eine 

Menge von Semaphoren, die zur selben Gruppe gehören. 

• Die Änderungen werden nur durchgeführt, wenn alle Semaphoren 

der Gruppe nicht durch die Änderung negativ werden; in diesem 

Fall wird gewartet ohne dass eine Änderung vollzogen wird. 

119 / 204



Semaphore 

Die Realisierung der Klasse SemaphoreGroup verwendet ein Integerarray 

(values) zur Darstellung der Semaphorwerte. Die Umsetzung mit 

mehreren Objekten vom Typ AdditiveSemaphore würde zu 

Verklemmungssituationen führen. 

SemaphoreGroup.java 

1 public class SemaphoreGroup { 

2 private int [] values ; 

4 public SemaphoreGroup ( int numberOfMembers ) { 

5 if( numberOfMembers



Semaphore 


1 public synchronized void changeValues ( int [] deltas ) { 

2 if( deltas . length != values . length ) 

3 return ; 

4 while (! canChange ( deltas )) { 

5 try { wait (); 


7 } 

8 doChange ( deltas ); 

9 notifyAll (); 

10 } 

Der Parameter der Methode changeValues gibt an, um welchen Wert die 

Semaphore jeweils verändert werden soll: deltas[i] gibt an, wie values[i] 

geändert werden soll; delta[i] kann positiv oder negativ sein. 

121 / 204



Semaphore 


1 private boolean canChange ( int [] deltas ) { 

2 for ( int i = 0; i < values . length ; i ++) 

3 if( values [i] + deltas [i] < 0) 

4 return false ; 

5 return true ; 

6 } 

8 private void doChange ( int [] deltas ) { 

9 for ( int i = 0; i < values . length ; i ++) 

10 values [i] = values [i] + deltas [i]; 

11 } 

13 public int getNumberOfMembers () { 

14 return values . length ; 

15 } 

Die private Methode canChange() gibt an, ob alle Änderungen durchführbar 

sind oder nicht. 

Die private Methode doChange führt die Änderungen durch. Danach werden in 

changeValues() alle wartenden Thread informiert (notifyAll()). 

Die öffentliche Methode getNumberOfMembers() dient zum Abfragen der 

Größe der Semaphorgruppe. 

Das Applet semgrp.html verdeutlicht den Gebrauch von Semaphorgruppen. 

122 / 204





Semaphore in ihren unterschiedlichen Ausprägungen sind Primitive der 

Interprozesskommunikation. Andere Primitive wurden entwickelt, sie sind 

aber alle jeweils durch Semaphore abbildbar, z.B.: 

• Hoare und Brich Hansen haben 1975 Monitore vorgeschlagen: 

ein Monitor ist eine gekapselte Datenstruktur, in der eine 

Bindungsvariable durch die Operationen WAIT und 

SIGNAL verwaltet wird. 

(vgl. Java Beispiele mit wait und notify) 

• Campell und Habermann führten 1974 Pfadausdrucke ein. 

• Atkinson und Hewitt diskutierten 1979 Serializer. 

123 / 204





Die bisher betrachteten Primitive haben vorausgesetzt, dass es einen 

gemeinsam nutzbaren Speicher gibt. 

Die Idee des Nachrichtenaustausch ist es, 

• ein Kommunikationsmedium (etwa ein Netz, einen Bus) zu 

verwenden, so dass 

• ein Prozess (Sender) einem anderen Prozess (Empfänger) eine 

Nachricht sendet. 

• Beide Prozesse synchronisieren sich automatisch, indem der 

Empfänger wartet, bis er eine Nachricht erhalten hat. 

Als Kommunikationsprimitive sind erforderlich: 

• send(destination, &message) und 

• receive(source, &message). 

Diese Thematik wird u.a. in der Vorlesung ” 

Verteilte Systeme“ 

behandelt. Hier wird wieder mittels Java auf 

• Message Queues und 

• Pipes 

eingegangen. 

124 / 204





Zunächst wird ein Puffer mit n Elemente definiert, der es erlaubt, Daten 

fester Grösse zwischen Sender und Empfänger auszutauschen. 

Dann wird gezeigt, wie Daten beliebiger Länger transferiert werden 

können. 

125 / 204




Puffer mit n Elementen 

• Der Erzeuger fügt Daten am 

Pufferende (Position tail ) ein. 

• Der Verbraucher entnimmt den Wert 

am Pufferanfang (an Position 0 

head )) und 

• reorganisiert den Puffer, d.h. alle 

Elemente werden nach oben 

verschoben. 

Was halten Sie von dieser Lösung? 

126 / 204




Puffer mit n Elementen 

Das Reorganisieren kann vermieden 

werden, wenn der Puffer zyklisch 

organisiert wird: 

127 / 204




Puffer in Java 

BufferN.java 

1 public class BufferN { 

2 private int head ; 

3 private int tail ; 

4 private int numberOfElements ; 

5 private int [] data ; 

7 public BufferN ( int n) { 

8 data = new int [n]; 

9 head = 0; 

10 tail = 0; 

11 numberOfElements = 0; 

12 } 

13 ... 

14 } 

128 / 204





BufferN.java 


2 while ( numberOfElements == data . length ) { 

3 try { 

4 wait (); 


6 } 

7 data [ tail ++] = x; 

8 if( tail == data . length ) 

9 tail = 0; 

10 numberOfElements ++; 


12 } 

Wenn der Puffer voll geworden ist, muss die Methode put() warten. Die 

Schleife ist erforderlich, da wir notifyAll() verwenden müssen. Wenn eine 

freie Position vorhanden ist, wird der Wert gespeichert und die Variable 

” tail“ zyklisch inkrementiert, danach wird ein wartender Thread geweckt. 129 / 204





BufferN.java 


2 while ( numberOfElements == 0) { 

3 try { 

4 wait (); 


6 } 

7 int result = data [ head ++]; 

8 if( head == data . length ) 

9 head = 0; 

10 numberOfElements - -; 



13 } 

Die Methode get() funktioniert analog. 

130 / 204




Message Queues 

Nun wird gezeigt, wie Daten beliebiger Länge ausgetauscht werden 

können. 

Dabei muss die Nachrichtengrenze bewahrt bleiben, d.h. wird z.B. 

Byte-Array gesendet so wird exakt diese Menge an Daten empfangen: 

131 / 204





MessagaQueue.java 

1 public class MessageQueue { 

2 private byte [][] msgQueue = null ; 

3 private int qsize = 0; // size of message queue as 

4 // number of entries ( not number of bytes ) 

5 private int head = 0; 

6 private int tail = 0; 

8 public MessageQueue ( int capacity ) { 

9 if( capacity






1 public synchronized void send ( byte [] msg ) { 

2 while ( qsize == msgQueue . length ) { 

3 try { 

4 wait (); 


6 } 

8 msgQueue [ tail ] = new byte [ msg . length ]; // copy message 

9 // and store the copy 

10 for ( int i = 0; i < msg . length ; i ++) 

11 msgQueue [ tail ][i] = msg [i]; 

12 qsize ++; 

13 tail ++; 

14 if( tail == msgQueue . length ) 

15 tail = 0; 


17 } 

133 / 204






1 public synchronized byte [] receive () { 

2 while ( qsize == 0) { 

3 try { 

4 wait (); 


6 } 

7 byte [] result = msgQueue [ head ]; 

8 msgQueue [ head ] = null ; 

9 qsize - -; 

10 head ++; 

11 if( head == msgQueue . length ) 

12 head = 0; 



15 } 

Durch ein Applet kann das Verhalten von MessagaQueue demonstriert 

werden. 

134 / 204




Pipes 

Message Queues bewahren die Nachrichtengrenzen; deshalb wird diese 

Art der Kommunikation auch ” 

nachrichtenorientiert“ genannt. 

Demgegenüber ist es für den Empfänger einer Nachricht bei 

streamorientierten“ Kommunkation nicht möglich, die einzelnen 

” 

Nachrichten zu unterscheiden, die an der Kommunikation beteiligt 

sind. 

Diese Verhalten verdeutlicht die Kommunikation über Pipes (mit einem 

Byte-Array fester Grösse) 

→ pipe 

135 / 204




Pipe in Java 

Pipe.java 

1 public class Pipe { 

2 private byte [] buffer = null ; 

3 private int bsize = 0; 

4 private int head = 0; 

5 private int tail = 0; 

7 public Pipe ( int capacity ) { 

8 if( capacity




Die send()-Operation, die Daten in eine Pipe schreibt, muss als atomare 

Operation realisiert werden: wenn die Nachricht grösser ist, als der noch 

verfügbar freie Platz in der Pipe, muss der Sender blockieren, bis ein 

Empfänger durch receive() Platz in der Pipe gemacht hat. 

Pipe.java 


2 if(msg . length buffer . length - bsize ) { 



7 } 

9 // copy message into buffer 

10 for ( int i = 0; i < msg . length ; i ++) { 

11 buffer [ tail ] = msg [i]; 

12 tail ++; 

13 if( tail == buffer . length ) 

14 tail = 0; 

15 } 

16 bsize += msg . length ; 


18 } else { 

19 ... 

137 / 204




Wenn die gesamte Länge der Nachricht grösser ist, als die Kapazität der 

Pipe, so wird die Nachricht in kleine Stücke geteilt und jeweils nur ein 

Stück gesendet. 


2 ... 

3 else { // send in portions 

4 int offset = 0; 

5 int stillToSend = msg . length ; 

6 while ( stillToSend > 0) { 

7 while ( bsize == buffer . length ) { 



10 } 

11 int sendNow = buffer . length - bsize ; 

12 if( stillToSend < sendNow ) sendNow = stillToSend ; 

13 for ( int i = 0; i < sendNow ; i ++) { 

14 buffer [ tail ] = msg [ offset ]; 

15 tail ++; 

16 if( tail == buffer . length ) tail = 0; 

17 offset ++; 

18 } 

19 bsize += sendNow ; stillToSend -= sendNow ; 


21 } 

22 } 

23 } 

138 / 204




Beim Empfang einer Nachricht, muss blockiert werden, bis Daten in der 

Pipe verfügbar sind. Ein Parameter beim receive() gibt die erwartete 

Grösse der Nachricht an; wenn weniger Daten in der Pipe sind, wird nicht 

blockiert, sondern nur der verfügbare Teil gelesen. 

Pipe.java 

1 public synchronized byte [] receive ( int noBytes ) { 

2 while ( bsize == 0) { 

3 try { 

4 wait (); 


6 } 

7 if( noBytes > bsize ) 

8 noBytes = bsize ; 

9 byte [] result = new byte [ noBytes ]; 

10 for ( int i = 0; i < noBytes ; i ++) { 

11 result [i] = buffer [ head ]; 

12 head ++; 

13 if( head == buffer . length ) 

14 head = 0; 

15 } 

16 bsize -= noBytes ; 



19 } 

20 } 

139 / 204


IPC Probleme 

IPC Problem 




Problem speisender Philosophen 

Lese-Schreiber Problem 

Das Problem des schlafenden Friseurs 

4 Scheduling 

140 / 204


IPC Probleme 


Problem speisender Philosophen (Dijkstra, 1965) 

• Fünf Philosophen sitzen um einen runden Tisch. 

• Jeder hat einen Teller mit Spagetti vor sich auf 

dem Teller. 

• Zwischen jedem Teller liegt eine Gabel. Um Essen 

zu können, braucht man immer zwei Gabeln. 

• Das Leben eines Philosophen besteht aus Essen 

und Denken. 

• Wenn ein Philosoph hungrig wird, versucht er die 

linke und rechte Gabel zu nehmen und zu Essen. 

Das Problem: 

Es ist ein Programm für einen Philosophen zu finden, das, auf 

alle Philosophen angewendet, nie dazu führt, dass einer der 

Philosophen verhungert. 

141 / 204


IPC Probleme 


Dieses Problem ist typisch für Betriebssysteme: es verdeutlicht den 

Wettbewerb um eine begrenzte Anzahl von exklusiv nutzbaren 

Betriebsmitteln, wie CPU oder E/A Geräte. 

Eine offensichtliche (aber nicht korrekte) Lösung in C 

ist: 

1 const int N =5; 

2 philosophers ( int i) { 


4 think (); 

5 takeFork (i); // take left fork 

6 take_fork ((i +1)% N); // take right fork 

7 eat (); 

8 putFork (i); // put left fork back 

9 putFork ((i +1)% N); // put right fork back 

10 } 

11 } 

Die Funktion takeFork() wartet, bis die entsprechende 

Gabel frei ist und nimmt dann die Gabel. Ist die Gabel 

nicht frei, wird eine Zeit lang gewartet und erneut 

versucht, die Gabel zu nehmen. 

Was halten Sie 

von dieser 

Lösung? 

142 / 204


IPC Probleme 


1 const int N =5; 

2 philosophers ( int i) { 


4 think (); 

5 takeFork (i); // take left fork 

6 take_fork ((i +1)% N); // take right fork 

7 eat (); 

8 putFork (i); // put left fork back 

9 putFork ((i +1)% N); // put right fork back 

10 } 

11 } 

Die Lösung funktioniert nicht, wenn z.B. alle Philosophen gleichzeitig die 

linke Gabel nehmen, da niemand die rechte Gabel nehmen kann und so 

alle verhungern (Deadlock). 

143 / 204


IPC Probleme 


Mit dem synchronized-Konzept von Java ist eine Lösung realisierbar, 

denn das Nehmen einer Gabel wird atomar: Philosophers.java 

1 class Table { 

2 private boolean [] usedFork ; 

4 public Table ( int numberForks ) { 

5 usedFork = new boolean [ numberForks ]; 

6 for ( int i = 0; i < usedFork . length ; i ++) 

7 usedFork [i] = false ; 

8 } 

10 private int left ( int i) { 

11 return i; 

12 } 

14 private int right ( int i) { 

15 if(i+1 < usedFork . length ) 

16 return i +1; 

17 else 

18 return 0; 

19 } 

20 

144 / 204


IPC Probleme 


21 public synchronized void takeForks ( int position ) { 

22 while ( usedFork [ left ( position )] 

23 || usedFork [ right ( position )]) { 

24 try { wait (); 


26 } 

27 usedFork [ left ( position )] = true ; 

28 usedFork [ right ( position )] = true ; 

29 } 

31 public synchronized void positionBackForks ( int position ) { 

32 usedFork [ left ( position )] = false ; 

33 usedFork [ right ( position )] = false ; 


35 } 

36 } // Table 

37 

145 / 204


IPC Probleme 


38 class Philosoph extends Thread { 

39 private Table Table ; 

40 private int position ; 

42 public Philosoph ( Table Table , int position ) { 

43 this . Table = Table ; 

44 this . position = position ; 

45 start (); 

46 } 

48 public void run () { life of a philosoph 


50 thinking ( position ); 

51 Table . takeForks ( position ); 

52 eating ( position ); 

53 Table . positionBackForks ( position ); 

54 } 

55 } 

57 private void thinking ( int position ) { 

58 System . out . println (" Philosoph " + position 

59 + " is thinking ."); 

60 try { 



63 } 

146 / 204


IPC Probleme 


65 private void eating ( int position ) { 


67 + " starts eating ."); 

68 try { 




72 + " finished eating ."); 

73 } 

74 } 

76 public class Philosophers { 

77 private static final int numberForks = 5; 


80 Table Table = new Table ( numberForks ); 

81 for ( int i = 0; i < numberForks ; i ++) 

82 new Philosoph ( Table , i); 

83 } 

84 } 

Hier eine Lösung, die Semaphorgruppen verwendet, um die Operation 

atomar zu machen. 

Ein Applet verdeutlicht dies. 

147 / 204


IPC Probleme 



Das Lese-Schreiber Problem modelliert den Zugriff auf eine Datenbank: 

Auf einen Datenbestand wollen mehrere Prozesse gleichzeitig 

zugreifen. 

• Es ist erlaubt, dass mehrere Prozesse gleichzeitig lesen, 

• aber nur einer darf zu einem Zeitpunkt schreiben. 

• Wenn geschrieben wird, darf kein Prozess (auch kein 

lesender) zugreifen. 

148 / 204


IPC Probleme 


1 semaphore mutex = 1; // controls access to rc 

2 semaphore db = 1; // controls access to DB 

3 int rc = 0; // # processes reading or wanting to 

5 reader () { 

6 while ( true ) { // repeat forever 

7 down ( mutex ); 

8 rc ++; 

9 if (rc == 1) down (db ); // for first reader 

10 up( mutex ); 

11 read_data_base (); 

12 down ( mutex ); 

13 rc - -; 

14 if (rc == 0) up(db ); // release if last reader 

15 up( mutex ); 

16 use_data_read (); 

17 } 

18 } 

19 writer () { 


21 think_up_data (); 

22 down (& db ); 

23 write_data_base ()(); // update the data 

24 up(db ); / 

25 } 

26 } 

Lösung in Java? → Übung 

Die Lösung dazu verwendet eine 

Semaphore db, um den Zugriff auf die 

Datenbank zu synchronisieren. 

• Der erste Leser (reader) ruft 

für den Zugriff auf den 

Datenbestand die Methode 

down() mit der Semaphore 

db“ auf, 

” 

• nachfolgende Leser erhöhen 

lediglich den Zähler ” 

rc“. 

• Wenn Leser den kritischen 

Bereich verlassen, erniedrigen 

sie den Zähler und 

• der letzte Leser ruft up() für 

die Semaphore auf und weckt 

einen potentiellen Schreiber. 

149 / 204


IPC Probleme 



In einem Friseursalon mit einem Friseurstuhl und n Stühlen für wartende 

Kunden arbeitet ein Friseur. 

• Falls kein Kunde die Haare geschnitten haben möchte (also alle 

Stühle leer sind), setzt sich der Friseur auf den Friseurstuhl und 

schläft. 

• Ein eintreffender Kunde muss den Friseur wecken, um die Haare 

geschnitten zu bekommen. 

• Während der Friseur Haare schneidet, müssen weitere Kunden 

entweder Platz nehmen und warten, bis der Friseur frei ist oder 

später nochmal kommen (falls alle Stühle besetzt sind). 

Lösung mit Semaphoren oder Java Synchronisation als Übung. 

150 / 204


IPC Probleme 


Lösungsidee 

Mittels Semaphore kann man das Problem lösen: 

customers Anzahl der Wartenden Kunden 

barbers Anzahl schlafender Frisöre 

mutex für den Schutz der Zählvariablen für wartende Kunden 

1 # define chairs 5 // # chairs for waiting customers 

2 typedef int semaphore ; // use your imagination 

3 semaphore customers = 0; // # customers waiting for service 

4 semaphore barbers = 0; // # barbers waiting for customers 

5 int waiting = 0; // customers are waiting , not being cut 

151 / 204


IPC Probleme 


Frisör, Kunde 

1 void barber ( void ) { 


3 down (& customers ); // go to sleep if # customers =0 

4 down (& mutex ); // acquire accesss to waiting 

5 waiting - -; // dec . cout of waiting customers 

6 up (& barbers ); // one barber is now ready to cut hairs 

7 up (& mutex ); // release waiting 

8 cut_hair (); 

9 } 

10 } 

11 void customer ( void ) { 

12 down (& mutex ); // enter critic region 

13 if ( waiting < chairs ) { // if there are no free chairs , leave 

14 waiting ++; 

15 up (& customers ); // wake up barber if necessary 

16 up (& mutex ); // release access to waiting 

17 down (& barbers ); // go to sleep if # of free barbers is 0 

18 get_haircut (); 

19 } else 

20 up (& mutex ); // shop is full ; do not wait 

21 } 

152 / 204


Scheduling 

Scheduling 




4 Scheduling 

Round-Robin Scheduling 

Scheduling mit Prioritäten 

Shortest-Job-First 

Garantiertes Scheduling 

Zweistufiges Scheduling 

Fallbeispiel: Linux Scheduler 

153 / 204


Scheduling 

Scheduling 

Der Teil des Betriebssystems, der entscheidet, 

• welcher der Prozesse, 

• die im Zustand bereit“ sind, 

” 

• ausgewählt wird und dann 

• den Prozessor zugeteilt bekommt, 

heißt Scheduler. 

Das Verfahren, wie ausgewählt wird, nennt man Scheduling-Algorithmus. 

154 / 204


Scheduling 

Kriterien für Scheduling-Algorithmus 

Fairness Jeder Prozess wird gleichermaßen berücksichtigt; es gibt 

keine privilegierten Prozesse. 

Effizienz Der Prozessor wird stets vollständig ausgelastet. 

Antwortzeit Die Antwortzeit für die interaktiv arbeitenden Benutzer 

wird minimiert. 

Verweilzeit Die Zeit, die auf Ausgabe von Stapelaufträge gewartet 

werden muss, ist minimal. 

Durchsatz Die Anzahl der Jobs, die in einem gegebenen Zeitintervall 

ausgeführt werden, wird maximiert. 

Ressourcenbedarf Der für die Implementierung benötigte 

Ressourcenbedarf ist minimal. 

Nicht alle Kriterien sind gleichzeitig zu erfüllen, da sie teilweise 

widersprüchlich sind (z.B. Antwortzeit – Verweilzeit). 

155 / 204


Scheduling 

Kategorisierung 

Ein Betriebssystem nutzt den Unterbrechungsmechanismus moderner 

CPU’s, um sicher zu stellen, dass kein Prozess zu lange ausgeführt wird: 

Wenn die Hardware einen Interrupt (etwa 100 mal pro Sekunde) 

ausgelöst hat, erhält das Betriebssystem die Kontrolle und der 

Scheduler wählt einen neuen Prozess aus. 

Je nachdem, wie der Scheduler die Auswahl der Prozesse vornimmt, 

werden Scheduling-Algorithmen unterschieden in: 

• preemptive Scheduling: 

rechnende Prozesse können unterbrochen werden. 

• run to completion (non-preemptive) Scheduling: 

der rechnende Prozess wird nicht unterbrochen. 

156 / 204


Scheduling 



Ein einfaches und häufig angewendetes Verfahren ist das Round-Robin 

Verfahren: 

• Jeder Prozess erhält eine Zeitscheibe (Quantum), die er maximal 

für die Ausführung zugeteilt bekommt. 

• Ist diese Zeit abgelaufen, wird ihm der Prozessor entzogen und 

• ein anderer Prozess wird ausgewählt. 

• Bei Blockierung wg. E/A wird dem Prozess der Prozessor entzogen, 

auch wenn sein Quantum noch nicht abgelaufen ist. 

Zur Implementierung verwaltet der Scheduler eine Queue mit 

rechenbereiten Prozessen, wobei ein aktiver Prozess nach Ablauf des 

Quantums wieder hinten in die Liste eingereiht wird: 

157 / 204


Scheduling 


Dauer für das Quantum 

Eine Implementierung dieses Verfahrens muss eine “richtige” Wahl für die 

Dauer des Quantums finden: 

Angenommen, ein Kontextwechsel dauert 5 Millisekunden. 

• Quantum=20 Millisekunden 

→ 5/20 ∗ 100 = 25% Verwaltungsaufwand sind zu viel. 

• Quantum=500 Millisekunden 

→ 5/500 ∗ 100 = 1% Verwaltungsaufwand bedeutet, dass u.U. ein 

Benutzer zu lange warten (5 Sekunde, wenn 10 Benutzer gleichzeitig 

arbeiten) muss, bevor seine Anfrage (Tastendruck während 

Editorsitzung) bearbeitet wird. 

158 / 204


Scheduling 



Folgerung: 

• Quantum zu klein → wegen häufiger Kontextwechsel sinkt 

Prozessorausnutzung 

• Quantum zu gross → schlechte Antwortzeiten bei vielen kurzen 

Anfragen 

• Erfahrungswert: Quantum=50 Millisekunden ist guter Kompromiss 

E/A intensive Prozesse, die häufig vor Ablauf des Quantums eine 

blockierende Systemfunktion aufrufen und damit den Prozessor entzogen 

bekommen, werden durch Round-Robin benachteiligt. 

159 / 204


Scheduling 



In Unix/Linux kann das Quantum des aktuellen Prozesses wie folgt 

ermittelt werden (in C): 

getQuantum.c 

1 # include 

2 # include < unistd .h> 

3 # include ← 

4 /* 

5 struct timespec { 

6 time_t tv_sec ; 

7 long tv_nsec ; // Nanosekunden =10** -9 Sekunden 

8 } ; 

9 */ 


11 struct timespec t; 

12 if ( sched_rr_get_interval ( getpid () ,&t )==0) ← 

13 printf (" sec : %d millisec : %ld\n", t. tv_sec , t. tv_nsec /1000000); 

14 } 

$ getQuantum 

sec : 0 millisec : 24 

$ 

160 / 204


Scheduling 



Die Grundidee des Prioritäts-Scheduling ist: 

• Jeder Prozess bekommt eine Priorität zugewiesen. 

• Es wird immer der rechenbereite Prozess mit der höchsten Priorität 

ausgeführt. 

Problem: 

Wird kein weiterer Mechanismus realisiert, so kommt es vor, 

dass Prozesse mit hoher Priorität verhindern, dass ein Prozess 

mit niedriger Priorität je den Prozessor bekommen 

(Verhungern). 

161 / 204


Scheduling 



Deshalb wird folgender Mechanismus als Lösung implementiert: 

• Der Scheduler verringert die Priorität des rechnenden Prozesses bei 

jedem Interrupt, der durch die interne Prozessoruhr ausgelöst wird. 

• Damit fällt die Priorität des laufenden Prozesses irgendwann unter 

die Priorität eines anderen rechenbereiten Prozesses; 

• in diesem Fall wird ein solcher rechenbereiter Prozess mit höherer 

Priorität ausgewählt. 

162 / 204


Scheduling 


Prioritäten können statisch oder dynamisch vergeben werden. 

statisch Die Priorität wird vor dem Prozessstart festgelegt. Z.B. 

kann man folgende Regel anwenden: 

Batchprozesse < Systemprozesse < Interaktive Prozesse < 

... 

dynamisch Dynamische Vergabe von Prioritäten wird häufig realisiert, 

um Systemziele zu erreichen. 

Z.B. Optimierung des I/O-Verhaltens: dann muss ein 

Prozess, der bei E/A Ereignis rechenbereit wird, hohe 

Priorität bekommen, damit das E/A Ereignis behandelt 

werden kann. 

163 / 204


Scheduling 


In modernen Betriebssystemen werden Prozesse in Klassen eingeteilt, 

wobei 

• zwischen den Klassen Prioritäts-Scheduling und 

• innerhalb der Klasse Round-Robin Scheduling 

verwendet wird. 

164 / 204


Scheduling 


Thread Prioritäten in Java 

Die JVM soll plattformunabhängig implementierbar sein. Daher gibt 

es in Java keine Vorgaben bzgl. des Scheduling. 

Methoden, mit denen die Priorität eines Thread beeinflusst werden kann: 

• Jeder Thread hat eine Priorität zwischen MIN PRIORITY und 

MAX PRIORITY ([1,10]). 

• Wird ein neuer Thread erzeugt, erbt er die Priorität vom Vater. 

• Der Defaultwert, wenn ein Thread aus main() erzeugt wurde, ist 

Thread.NORM PRIORITY (5). 

• Die Methode getPriority() liefert die aktuelle Priorität eines Threads. 

• Mit setPriority()kann die Priorität verändert werden. 

165 / 204


Scheduling 


Thread Prioritäten in Java 

Achtung: 

• Prioritäten beeinflussen weder Semantik noch Korrektheit eines 

Java Programms. 

• Prioritäten dürfen beim Programmieren nicht als Ersatz für Locking 

verwendet werden! 

• Prioritäten dürfen nur verwendet werden, um die relative 

Wichtigkeit unterschiedlicher Threads untereinander zu definieren. 

166 / 204


Scheduling 


3 Threads mit unterschiedlicher Priorität in Java I 

ThreadPriority.java 

1 import java . util .*; 

2 import java .io .*; 

4 class ThreadPriority { 


6 ThreadPriority t = new ThreadPriority (); 

7 t. doIt (); 

8 } 

10 public void doIt () { 

11 MyThread t1 = new MyThread (" Thread One : "); 

12 t1. setPriority (t1. getPriority () -4); // Default is 5 

13 MyThread t2 = new MyThread (" Thread Two : "); 

14 MyThread t3 = new MyThread (" Thread Three : "); 

15 t3. setPriority (10); 

16 t1. start (); 

17 t3. start (); 

18 t2. start (); 

19 } 

20 } 

21 

167 / 204


Scheduling 


3 Threads mit unterschiedlicher Priorität in Java II 


22 class MyThread extends Thread { 

23 static String spacerString =""; 

24 public String filler ; 

26 public MyThread ( String ThreadNameIn ) { 

27 filler = spacerString ; 

28 spacerString = spacerString + " "; 

29 setName ( ThreadNameIn ); 

30 } 


33 for ( int k =0; k < 5; k ++) { 

34 System . out . println ( filler + 

35 Thread . currentThread (). getName () + 

36 " Iteration = " + Integer . toString (k) ) ; 

37 } 

38 } 

39 } 

168 / 204


Scheduling 


3 Threads mit unterschiedlicher Priorität in Java 


$ java ThreadPriority 

Thread Three : Iteration = 0 





Thread One : Iteration = 0 





Thread Two : Iteration = 0 





Versuche Sie das Programm auf Ihrem Rechner. 

Ist die Ausgabe genau so ? 

169 / 204


Scheduling 


Prozessprioritäten in Unix/Linux 

In Linux ist die Priorität eines Prozesses ein Integer im Bereich -20 bis 20 

(-20 ist höchste Priorität, Default ist 0). 

Das folgende Programm zeigt, wie die Priorität eines Prozesses gesetzt 

und abgefragt werden kann: getPriority.c 

1 # include 

2 # include 

3 # include // wg. PRIO_USER 

4 # include 

6 extern int errno ; 


8 int prio = 0; 

9 if ( setpriority ( PRIO_USER , 0, 10) != 0) { ← 

10 fprintf ( stderr , " Error setpriority : %s\n", strerror ( errno )); 

11 exit (1); 

12 } 

13 printf ("%d\n", getpriority ( PRIO_USER , 0)); ← 

14 exit (0); 

15 } 

170 / 204


Scheduling 



Die beiden letzten Verfahren sind für interaktive Systeme entworfen 

worden. 

Ein Verfahren für Systeme, bei denen die Ausführungszeiten der 

einzelnen Prozesse im voraus bekannt sind, benutzt eine Warteschlange 

für die gleichgewichtigen Prozesse. 

Der Scheduler wählt den Prozess mit der kürzesten 

Ausführungszeit zuerst. 

Gemäss dieser Methode wird die durchschnittliche Verweilzeit (Zeit, 

die der Prozess im System verweilt ) von Prozessen minimiert: 

171 / 204


Scheduling 


Gegeben seien 4 Prozesse mit folgenden Ausführungszeiten: 

A 8 Sekunden 

B 6 Sekunden 

C 4 Sekunden 

D 6 Sekunden 

Ausführungsreihenfolge A, B, C, D: 

Verweilzeit 

A 8 

B 8 + 6 = 14 

C 8 + 6 + 4 = 18 

D 8 + 6 + 4 + 6 = 24 

→ durchschnittliche Verweilzeit = (8 + 14 + 18 + 24)/4 = 16 

172 / 204


Scheduling 



A 8 Sekunden 

B 6 Sekunden 

C 4 Sekunden 

D 6 Sekunden 

Ausführungsreihenfolge C, B, C, A: 

Verweilzeit 

C 4 

B 4 + 6 = 10 

D 4 + 6 + 6 = 16 

A 4 + 6 + 6 + 8 = 24 

→ durchschnittliche Verweilzeit = (4 + 10 + 16 + 24)/4 = 13, 5 

173 / 204


Scheduling 


Behauptung: 

Den Prozess mit der kürzesten Ausführungszeit zu wählen ist 

optimal bzgl. der mittleren Verweilzeit. 

Beweis: 

Gegeben seien 4 Prozesse A-D mit den jeweiligen Verweilzeiten 

a, b, c, d, die in der Reihenfolge A,B,C,D ausgeführt werden. 

Verweilzeit 

A a 

B a + b 

C a + b + c 

D a + b + c + d 

→ durchschnittliche Verweilzeit = (4a + 3b + 2c + d)/4 

d.h. a beeinflusst die durchschnittliche Verweilzeit am meisten, 

gefolgt von b und c; daraus folgt: 

die durchschnittliche Verweilzeit ist minimal, wenn zuerst A der 

Prozess mit der kleinsten Ausführungszeit ist, B der Prozess mit 

der zweit kleinsten Ausführungszeit, etc 

174 / 204


Scheduling 


Ausführungszeit bestimmen 

Das Problem bei interaktiven Betriebssystemen ist es, die 

Ausführungszeit der Prozesse zu bestimmen. 

Idee: 

Schätze die Ausführungszeit auf Basis der gemessenen Zeit 

der Vergangenheit M. 

• Der Scheduler wählt dann den Prozess mit der kürzesten 

geschätzten Zeit. 

• Der neue geschätzte Wert S zum Zeitpunkt n+1 wird aus 

dem gewichteten Durchschnitt des aktuellen und des 

vorherigen Wertes gebildet. 

S n+1 = α ∗ M n + (1 − α) ∗ S n 

α(0 ≤ α ≤ 1) ist dabei der Faktor, der den Einfluss der 

zurückliegenden Periode auf die Schätzung angibt; Werte 

nahe 1 ordnen der geschätzten Vergangenheit wenig 

Stellenwert zu. 

175 / 204


Scheduling 




A 6 Sekunden 

B 6 Sekunden 

C 8 Sekunden 

D 2 Sekunden 

E 4 Sekunden 

Welche Ausführungsreihenfolge führt zur optimalen durchschnittlichen 

Verweilzeit? 

Prozess 

A 

B 

C 

D 

E 

Verweilzeit 

→ durchschnittliche Verweilzeit = 

176 / 204


Scheduling 



Beim garantierten Scheduling wird einem Prozess eine gewisse 

Performance versprochen und die Einhaltung garantiert. 

Mögliche Versprechen: 

• Bei interaktiven Systemen mit n Benutzern, erhält jeder 1/n der 

verfügbaren Prozessorzeit 

• Bei Echtzeitsystemen wird vom System garantiert, dass ein 

Prozess innerhalb einer Zeitschranke abgeschlossen ist. 

177 / 204


Scheduling 


interaktive Systeme 

Zu jeder Benutzersitzung sei die insgesamt erhaltene Prozessorzeit seit 

Sitzungsbeginn e. 

Beispiel 

Der Scheduler berechnet die dem Benutzer zustehende Zeit z 

und ermittelt das Verhältnis von erhaltener Zeit e und 

zustehender Zeit z. 

Das Verhältnis 0,5 bedeutet, dass der Prozess halb so viel Zeit 

verbraucht hat, wie ihm garantiert wurde. 

Der Scheduler wählt immer den Prozess, mit dem 

berechneten kleinsten Verhältnis e/z. 

Prozess erhaltene versprochene e/z ausgewählter 

Zeit e Zeit z Prozess 

A 14 (14+11+20)/3=15 14/15=0,93 

B 11 (14+11+20)/3=15 11/15=0,73 X 

C 20 (14+11+20)/3=15 20/15=1,33 

178 / 204


Scheduling 


Echtzeit-Systeme 

Bei Echtzeitsystemen wird vom System garantiert, dass ein Prozess 

innerhalb einer Zeitschranke abgeschlossen ist. 

Beispiel 

Der Scheduler wählt den Prozess, bei dem die Gefahr am 

grössten ist, dass die Zeitschranke nicht eingehalten werden 

kann. 

Prozess zugesicherte bisher er- Dauer bis Ablauf ausgewählter 

Zeitschranke haltene Zeit der Zeitschranke Prozess 

A 14 10 14-10=4 

B 11 9 11-9=2 X 

C 20 15 20-15=5 

179 / 204


Scheduling 



1. Ein interaktives System sei geben durch: 

Prozess erhaltene versprochene e/z ausgewählter 

Zeit e Zeit z Prozess 

A 8 

B 2 

C 2 

D 2 

2. Ein Echtzeitsystem sei gegeben durch: 

Prozess zugesicherte bisher er- Dauer bis Ablauf ausgewählter 

Zeitschranke haltend Zeit der Zeitschranke Prozess 

A 4 1 

B 2 1 

C 2 1 

D 6 2 

In welcher Reihenfolge werden die Prozesse in beiden Systemen 

ausgewählt (jeweils 5 Kontextwechsel, Quantum 1 Sekunde)? 

180 / 204


Scheduling 



Die bisherigen Scheduling-Verfahren haben gemeinsam, dass alle 

rechenbereiten Prozesse im Hauptspeicher ablaufen. 

• Wenn nicht genug Hauptspeicher verfügbar ist, müssen einige dieser 

Prozesse auf der Festplatte abgelegt werden. 

• Der Aufwand für einen Prozesswechsel ist aber höher, wenn ein 

Prozess zunächst in den Hauptspeicher zurückgeladen werden muss. 

181 / 204


Scheduling 


Ein zweistufiges Verfahren teilt die 

rechenbereiten Prozesse in 2 disjunkte 

Teilmengen: 

• Prozesse im Hauptspeicher H 

• Prozesse auf Platte (Sekundärspeicher 

S) 

Es existieren zwei Scheduler: 

• lokaler Scheduler wählt stets einen 

Prozess aus H 

• periodisch lagert ein globaler Scheduler 

Prozesse von H und S aus und ersetzt 

sie. 

182 / 204


Scheduling 


Als Verfahren für den lokalen Scheduler 

kommt einer der vorherigen Algorithmen in 

Frage. 

Der globale Scheduler kann folgende 

Kriterien zur Auswahl des Plattenspeicher 

Prozesses, der ausgetauscht werden soll: 

• Wie lange ist der Prozess schon in S? 

• Wie groß ist der Prozess in S (es 

passen mehrere kleine in den 

Hauptspeicher)? 

• Priorität des Prozesses in S? 

183 / 204


Scheduling 



Die Beschreibung basiert auf dem Beitrag ” 

Der O(1)-Scheduler im Kernel 

2.6“ von Timo Hönig im Linux-Magazin. 

184 / 204


Scheduling 


Prozessverwaltung 

• Linux verwaltet alle Prozessinformationen 

mit Hilfe einer doppelt verketteten Liste - 

der Taskliste. 

• Die Listenelemente sind die 

Prozessdeskriptoren (≫task struct≪) der 

Prozesse. 

• Der Deskriptor hält alle Informationen 

seines Prozesses fest (im Wesentlichen, 

das was man mit ps sieht). 

185 / 204


Scheduling 


Den Zustand eines Prozesses speichert die Variable ≫state≪ des 

Prozessdeskriptors. 

Der Scheduler kennt insgesamt fünf Zustände: 

1 TASK RUNNING kennzeichnet den Prozess als lauffähig. 

Er muss auf kein Ereignis warten und kann daher vom Scheduler der 

CPU zugeordnet werden. Alle Prozesse im Zustand 

≫TASK RUNNING≪ zieht der Scheduler für die Ausführung in 

Betracht. 

2 TASK INTERRUPTIBLE kennzeichnet blockierte Prozesse. 

Der Prozess wartet auf ein Ereignis. Ein Prozess im Zustand 

TASK INTERRUPTIBLE wird über zwei unterschiedliche Wege in 

den Zustand TASK RUNNING versetzt: 

1 Entweder tritt das Ereignis ein, auf das er gewartet hat, 

2 oder der Prozess wird durch ein Signal aufgeweckt. 

186 / 204


Scheduling 


3 TASK UNINTERRUPTIBLE gleicht dem Zustand 

TASK INTERRUPTIBLE, mit dem Unterschied, dass ein Signal den 

Prozess nicht aufwecken kann. 

Der Zustand TASK UNINTERRUPTIBLE wird nur verwendet, wenn 

zu erwarten ist, dass das Ereignis, auf das der Prozess wartet, zügig 

eintritt, oder wenn der Prozess ohne Unterbrechung warten soll. 

4 Wurde ein Prozess beendet, dessen Elternprozess noch nicht den 

Systemaufruf ≫wait4()≪ ausgeführt hat, verbleibt er im Zustand 

TASK ZOMBIE. So kann auch nach dem Beenden eines 

Kindprozesses der Elternprozess noch auf seine Daten zugreifen. 

Nachdem der Elternprozess ≫wait4()≪ aufgerufen hat, wird der 

Kindprozess endgültig beendet, seine Datenstrukturen werden 

gelöscht. Endet ein Elternprozess vor seinen Kindprozessen, 

bekommt jedes Kind einen neuen Elternprozess zugeordnet. Dieser 

ist nunmehr dafür verant- wortlich, ≫wait4()≪ aufzurufen, sobald 

der Kindprozess beendet wird. Ansonsten könnten die Kindprozesse 

den Zustand TASK ZOMBIE nicht verlassen und würden als Leichen 

im Hauptspeicher zurückbleiben. 

187 / 204


Scheduling 


5 Den Zustand TASK STOPPED 

erreicht ein Prozess, wenn er beendet 

wurde und nicht weiter ausführbar ist. 

In diesen Zustand tritt der Prozess ein, 

sobald er eines der Signale 

≫SIGSTOP≪, ≫SIGTST≪, 

≫SIGTTIN≪ oder ≫SIGTTOU≪ erhält. 

188 / 204


Scheduling 


Entwicklungsziele für den Scheduler 

Neben den allgemeinen Zielen (Auslastung der CPU, ...) waren hier 

zusätzlich folgende Punkte maßgebend: 

• gute SMP-Skalierung 

• geringe Latenz auch bei hoher Systemlast 

• faire Prioritätenverteilung 

• Komplexität der Ordnung O(1) 

Alle Linux-Scheduler bisher besaßen eine Komplexität der Ordnung O(n): Die 

Kosten für das Scheduling wuchsen linear mit der Anzahl n der lauffähigen 

Prozesse. Bei einem Kontextwechsel wird in einer verketteten Liste nach einem 

Prozess gesucht, dessen Priorität am niedrigsten ist. 

189 / 204


Scheduling 


Prozessprioritäten 

Die Prozessprioritäten entscheiden, welchen lauffähigen Prozess die CPU 

beim nächsten Kontextwechsel zugeteilt bekommt - den mit der zum 

Zeitpunkt des Kontextwechsels höchsten Priorität. Die Priorität eines 

Prozesses ändert sich dabei dynamisch während seiner Laufzeit. 

Es gibt zwei unterschiedliche Prioritäten: 

• die statische Prozesspriorität, also die vom ≫nice≪-Wert bestimmte 

≫static prio≪ 

Der Wertebereich des ≫nice≪-Values reicht von -20 (dem höchsten) 

bis 19 (dem niedrigsten). 

• die dynamische (effektive) Prozesspriorität (≫prio≪), die der 

Scheduler aufgrund der Interaktivität eines Prozesses berechnet. 

190 / 204


Scheduling 


Linux 2.6 kennt standardmäßig 140 

Prioritätslevels. 

• Hierbei entspricht null der höchsten 

und 139 der niedrigsten Priorität. 

• Die Levels von eins bis 99 sind für 

Tasks mit Echtzeitpriorität reserviert. 

• Alle anderen Prozesse erhalten 

zunächst gemäß ihres ≫nice≪-Werts 

eine Priorität: Der ≫nice≪-Wert (-20 

bis 19) wird einfach in den Bereich ab 

101 gemappt. 

• Während des Ablaufs eines Prozesses 

verändert sich durch seinen 

Interaktivitätsgrad aber seine Priorität. 

191 / 204


Scheduling 


Alle lauffähigen Prozesse verwaltet der Scheduler in einer Run-Queue (pro 

CPU). Sie ist die zentrale Datenstruktur, auf der der Scheduler arbeitet. 

struct runqueue { 

/* Spinlock um Run - Queue zu schützen */ 

spinlock_t lock ; 

/* Zahl der lauffähigen Prozesse */ 

unsigned long nr_running ; 

/* Zahl der bisherigen Kontextwechsel */ 

unsigned long nr_switches ; 

/* Zeitstempel des letzten Tauschs von active - und expired - Array */ 

unsigned long expired_timestamp ; 

/* Zahl der Prozess im Zustand TASK_UNINTERRUPTIBLE */ 

unsigned long nr_uninterruptible ; 

/* Verweis auf Prozessdeskriptor des momentan ablaufenden Prozesses */ 

task_t * curr ; 

/* Verweis auf Prozessdeskriptor der Idle - Task */ 

task_t * idle ; 

/* Verweis auf Memory Map des zuletzt ablaufenden Prozesses */ 

struct mm_struct * prev_mm ; 

/* Verweise auf active - und expired - Array */ 

prio_array_t * active , * expired ; 

/* Priority - Arrays */ 

prio_array_t arrays [2]; 

... } 

192 / 204


Scheduling 


Neben Verweisen auf die gerade laufende Task, enthält die Run-Queue 

Verweise zu den zwei Priority-Arrays ≫active≪ und ≫expired≪. 

struct prio_array { 

int nr_active ; /* Zahl der Prozesse */ 

unsigned long bitmap [ BITMAP_SIZE ]; /* Priorität - Bitmap */ 

/* Für jede Priorität eine Liste der Prozesse */ 

struct list_head queue [ MAX_PRIO ]; 

}; 

• Das ≫active≪-Array listet alle lauffähigen Prozesse, deren 

Zeitscheibe noch nicht abgelaufen ist. 

• Wenn die Zeitscheibe eines Prozesse abläuft, verschiebt der 

Scheduler den Eintrag vom ≫active≪- in das zweite Array 

≫expired≪. 

• Beide, das ≫active≪- und das ≫expired≪-Array, führen für jede 

Priorität eine verkettete Liste der Prozesse mit entsprechender 

Priorität. 

• Eine Bitmap hält fest, für welche Priorität mindestens eine Task 

existiert. Alle Bits werden bei der Initialisierung auf null gesetzt. 

Beim Eintragen eines Prozesses in eines der beiden Priority-Arrays, 

wechselt entsprechend der Priorität des Prozesses das 

korrespondierende Bit im Priorität-Bitmap auf eins. 

193 / 204


Scheduling 


• Startet ein Prozess mit dem Nice null, setzt 

der Scheduler das 120. Bit des Priorität-Bitmaps 

im ≫active≪-Array und reiht ihn in die 

Prozessliste mit Priorität 120 ein. 

• Analog dazu löscht sich das entsprechende Bit 

im Priorität-Bitmap, sobald der Scheduler den 

letzten Prozess einer gegebenen Priorität aus 

einem der beiden Priority-Arrays austrägt. 

• Der Scheduler muss nur das erste gesetzte Bit 

des Priorität-Bitmaps finden (da Bitmap 

konstante Größe hat folgt O(1)). Anschließend 

führt der Scheduler den ersten Prozess aus der 

verketteten Liste dieser Priorität aus. Prozesse 

gleicher Priorität bekommen die CPU 

nacheinander in einem Ringverfahren (Round 

Robin) zugeteilt. 

194 / 204


Scheduling 


Prozess-Zeitscheiben und Neuberechnung der Prioritäten 

Die Größe der Zeitscheibe eines Prozesses ist von seiner Priorität 

abhängig: 

• Prozesse mit hoher Priorität erhalten mehr CPU-Zeit als solche 

mit niedriger. 

• Die kleinste Zeitscheibe beträgt 10, die längste 200 Millisekunden. 

Ein Prozess mit dem ≫nice≪-Wert null erhält die Standard- 

Zeitscheibe von 100 Millisekunden. 

Ist die Zeitscheibe eines Prozesses aufgebraucht, muss der Scheduler 

sie neu berechnen und den Prozess aus dem ≫active≪- in das 

≫expired≪-Array verschieben. Sobald ≫active≪ leer ist - alle 

lauffähigen Prozesse haben ihre Zeitscheibe aufgebraucht -, tauscht der 

Scheduler einfach das ≫active≪- gegen das ≫expired≪-Array aus. 

Effektiv wechseln nur die zwei Pointer der Run-Queue die Plätze. 

In Linux 2.4 werden die Zeitscheiben aller Prozesse auf einmal neu berechnet - immer dann, wenn alle Prozesse ihre Zeitscheiben 

aufgebraucht haben. Mit steigender Prozesszahl dauert die Berechnung immer länger. 

195 / 204


Scheduling 


Die dynamische Priorität errechnet der Scheduler aus der statischen 

und der Prozessinter- aktivität. Gemäß seiner Interaktivität erhält ein 

Prozess vom Scheduler entweder einen Bonus oder ein Penalty (Malus). 

Interaktive Prozesse gewinnen über einen Bonus maximal fünf 

Prioritätslevels hinzu, während jene Prozesse, die eine geringe 

Interaktivität aufweisen, maximal fünf Prioritätslevels durch ein Penalty 

verlieren. Die dynamische Priorität eines Prozesses mit einem 

≫nice≪-Wert fünf beträgt demnach im besten Fall null und im 

schlechtesten zehn. 

196 / 204


Scheduling 


Um den Grad der Interaktivität eines Prozesses zu bestimmen, muss 

bekannt sein, ob der Prozess eher I/O-lastig oder eher CPU-intensiv ist. 

Um Prozesse einer der beiden Kategorien zuordnen zu können, 

protokolliert der Kernel für jeden Prozess, wie viel Zeit er mit 

Schlafen verbringt, und wie lange er die CPU in Anspruch nimmt. Die 

Variable ≫sleep avg≪ (Sleep Average) im Prozessdeskriptor speichert 

dafür eine Entsprechung in dem Wertebereich von null und zehn 

(≫MAX SLEEP AVG≪). 

Läuft ein Prozess, verringert seine ≫sleep avg≪ mit jedem 

Timer-Tick ihren Wert. Sobald ein schlafender Prozess aufgeweckt wird 

und in den Zustand ≫TASK RUNNING≪ wechselt, wird 

≫sleep avg≪ entsprechend seiner Schlafzeit erhöht - maximal bis zu 

≫MAX SLEEP AVG≪. Der Wert von ≫sleep avg≪ ist somit maßgebend, 

ob ein Prozess I/O- oder Processor-Bound ist. Interaktive Prozesse haben 

eine hohe ≫sleep avg≪, minder interaktive eine niedrige. 

197 / 204


Scheduling 


Mit der Funktion ≫effective prio()≪ berechnet der Scheduler die 

dynamische Priorität ≫prio≪ basierend auf der statischen 

≫static prio≪ und der Interaktivität ≫sleep avg≪ des Prozesses. Zum 

Berechnen der neuen Zeitscheibe greift der Scheduler auf die dynamische 

Prozesspriorität zurück. Dazu mappt er den Wert in den 

Zeitscheibenbereich ≫MIN TIMESLICE≪ (Default: 10 Millisekunden) bis 

≫MAX TIMESLICE≪ (200 Millisekunden). 

Interaktive Prozesse mit hohem Bonus und großer Zeitscheibe können 

ihre Priorität jedoch nicht missbrauchen, um die CPU zu blockieren: Da 

die Zeit, die der Prozess beim Ausführen im Zustand 

≫TASK RUNNING≪ verbringt, in die Berechnung der 

≫sleep avg≪-Variablen eingeht, verliert solch ein Prozess schnell seinen 

Bonus und mit ihm seine hohe Priorität und seine große Zeitscheibe. 

Ein Prozess mit sehr hoher Interaktivität erhält nicht nur eine hohe 

dynamische Priorität und somit eine große Zeitscheibe: Der Scheduler 

trägt den Prozess nach Ablauf seiner Zeitscheibe auch wieder sofort in 

das ≫active≪-Array ein, statt wie gewöhnlich ins ≫expired≪-Array. Der 

Prozess wird dadurch seiner Priorität gemäß wieder zugeordnet und muss 

nicht auf das Austauschen der Priority-Arrays warten. 

198 / 204


Scheduling 


Kontextwechsel 

Alle blockierten Prozesse werden in den so genannten Wait-Queues 

verwaltet. Prozesse, die von ≫TASK RUNNING≪ in den Zustand 

≫TASK INTERRUPTIBLE≪ oder ≫TASK 

UNINTERRUPTIBLE≪ wechseln, gelangen in diese Warteschlange. 

Anschließend ruft der Kernel ≫schedule()≪ auf, damit ein anderer 

Prozess die CPU erhält. 

Sobald das Ereignis eintritt, auf das der Prozess in einer Wait-Queue 

wartet, wird er aufgeweckt, wechselt seinen Zustand in 

≫TASK RUNNING≪ zurück, verlässt die Wait-Queue und betritt die 

Run-Queue. Falls der aufgewachte Prozess eine höhere Priorität besitzt 

als der gerade ablaufende, unterbricht der Scheduler den aktuell 

laufenden Prozess zugunsten des eben aufgewachten. 

199 / 204


Scheduling 


Kernel-Preemption 

Anders als Kernel 2.4 ist der neue Linux-Kernel preemptiv: Kernelcode, 

der gerade ausgeführt wird, kann unterbrochen werden. Vor dem 

Unterbrechen muss gewährleistet sein, dass sich der Kernel in einem 

Zustand befindet, der eine Neuzuordnung der Prozesse zulässt. 

Die Struktur ≫thread info≪ jedes Prozesses enthält zu diesem Zweck den 

Zähler ≫preempt count≪. Ist er null, ist der Kernel in einem sicheren 

Zustand und darf unterbrochen werden. Die Funktion 

≫preempt disable()≪ erhöht den Zähler ≫preempt count≪ beim Setzten 

eines so genannten Locks um eins; die Funktion 

≫preempt enable()≪ erniedrigt ihn um eins, sobald ein Lock aufgelöst 

wird. Das Setzten des Locks (und damit das Verbot der 

Kernel-Preemption) wird immer dann notwendig, wenn beispielsweise eine 

von zwei Prozessen genutzte Variable vor konkurrierenden Zugriffen zu 

sichern ist. 

200 / 204


Scheduling 


Realtimefähigkeit 

Für Prozesse mit so Echtzeitpriorität (Priorität 1 bis 99) gibt es zwei 

Strategien: 

• ≫SCHED FIFO≪ 

ist ein einfacher First-in/First-out-Algorithmus, der ohne 

Zeitscheiben arbeitet. Wird ein Echtzeitprozess mit 

≫SCHED FIFO≪ gestartet, läuft er so lange, bis er blockiert oder 

freiwillig über die Funktion ≫sched yield()≪ den Prozessor abgibt. 

Alle anderen Prozesse mit einer niedrigeren Priorität sind solange 

blockiert und werden nicht ausgeführt. 

• ≫SCHED RR≪ 

verfolgt die gleiche Strategie wie ≫SCHED FIFO≪, aber zusätzlich 

mit vorgegebenen Zeitscheiben. 

Die CPU-Bedürfnisse der Echtzeitprozesse gleicher Priorität befriedigt der 

Scheduler per Round-Robin. Prozesse mit einer niedrigeren Priorität 

kommen überhaupt nicht zum Zuge. Der Scheduler vergibt für 

Echtzeitprozesse keine dynamischen Prioritäten. Prozesse ohne 

Echtzeitpriorität führt er mit der Strategie ≫SCHED OTHER≪ aus. 

201 / 204


Scheduling 


Realtimefähigkeit 

Die Echtzeit-Strategien von Linux garantieren jedoch keine 

Antwortzeiten, was die Voraussetzung für ein hartes 

Echtzeit-Betriebssystem wäre. 

Der Kernel stellt jedoch sicher, dass ein lauffähiger Echtzeit-Prozess 

immer die CPU bekommt, wenn er auf kein Ereignis warten muss, er 

freiwillig die CPU abgibt und wenn kein lauffähiger Echtzeitprozess 

höherer Priorität existiert. 

202 / 204


Scheduling 


Leistungsvergleich O(n) vs O(1) Scheduler 

Benötigte Zeit zur Interprozess-Kommunikation in Abhängigkeit von der 

Anzahl beteiligter Prozesse auf einem Singleprozessor-System mit Kernel 

2.4 (rot) und 2.6 (grün): 

203 / 204


Scheduling 


Benötigte Zeit zur Interprozess-Kommunikation in Abhängigkeit von der 

Anzahl beteiligter Prozesse auf Systemen mit ein, zwei, vier und acht 

CPUs. 

Es ist deutlich zu sehen, dass Linux 2.6 bei steigender Prozesszahl auf 

allen vier Systemen ungleich besser skaliert als der alte Kernel. 

204 / 204

Betriebssysteme - Prozesse

Erfolgreiche ePaper selbst erstellen

Template löschen?

Als Template speichern?