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

Java ist auch eine Insel von Christian Ullenboom
Programmieren für die Java 2-Plattform in der Version 5 (Tiger-Release)
Buch: Java ist auch eine Insel
gp Kapitel 9 Threads und nebenläufige Programmierung
  gp 9.1 Prozesse und Threads
    gp 9.1.1 Wie parallele Programme die Geschwindigkeit steigern können
  gp 9.2 Threads erzeugen
    gp 9.2.1 Threads über die Schnittstelle Runnable implementieren
    gp 9.2.2 Threads über Runnable starten
    gp 9.2.3 Die Klasse Thread erweitern
    gp 9.2.4 Erweitern von Thread oder Implementieren von Runnable?
  gp 9.3 Die Zustände eines Threads
    gp 9.3.1 Das Ende eines Threads
    gp 9.3.2 Einen Thread höflich mit Interrupt beenden
    gp 9.3.3 Der stop() von außen
    gp 9.3.4 Das ThreadDeath-Objekt
    gp 9.3.5 Auf das Ende warten mit join()
    gp 9.3.6 Threads schlafen
    gp 9.3.7 Eine Zeituhr
  gp 9.4 Arbeit niederlegen und wieder aufnehmen
  gp 9.5 Priorität
    gp 9.5.1 Threads hoher Priorität und das AWT
    gp 9.5.2 Granularität und Vorrang
  gp 9.6 Dämonen
  gp 9.7 Kooperative und nichtkooperative Threads
  gp 9.8 Synchronisation über kritische Abschnitte
    gp 9.8.1 Gemeinsam genutzte Daten
    gp 9.8.2 Probleme beim gemeinsamen Zugriff und kritische Abschnitte
    gp 9.8.3 Punkte parallel initialisieren
    gp 9.8.4 i++ sieht atomar aus, ist es aber nicht
    gp 9.8.5 Abschnitte mit synchronized schützen
    gp 9.8.6 Monitore
    gp 9.8.7 Synchronized-Methode am Beispiel der Klasse StringBuffer
    gp 9.8.8 Synchronisierte Blöcke
    gp 9.8.9 Vor- und Nachteile von synchronisierten Blöcken und Methoden
    gp 9.8.10 Nachträglich synchronisieren
    gp 9.8.11 Monitore sind reentrant, gut für die Geschwindigkeit
    gp 9.8.12 Deadlocks
    gp 9.8.13 Erkennen von Deadlocks
  gp 9.9 Synchronisation über Warten und Benachrichtigen
    gp 9.9.1 Warten mit wait() und Aufwecken mit notify()
    gp 9.9.2 Falls der Lock fehlt: IllegalMonitorStateException
    gp 9.9.3 Mehrere Wartende und notifyAll()
    gp 9.9.4 wait() mit einer Zeitspanne
    gp 9.9.5 Beispiel Erzeuger-Verbraucher-Programm
    gp 9.9.6 Semaphoren
  gp 9.10 Atomares und frische Werte mit volatile
    gp 9.10.1 Das Paket java.util.concurrent.atomic
  gp 9.11 Aktive Threads in der Umgebung
  gp 9.12 Gruppen von Threads in einer Thread-Gruppe
    gp 9.12.1 Etwas über die aktuelle Thread-Gruppe herausfinden
    gp 9.12.2 Threads in einer Thread-Gruppe anlegen
    gp 9.12.3 Methoden von Thread und ThreadGroup im Vergleich
  gp 9.13 Die Klassen Timer und TimerTask
    gp 9.13.1 Job-Scheduler Quartz
  gp 9.14 Einen Abbruch der virtuellen Maschine erkennen


Galileo Computing

9.5 Prioritädowntop

Jeder Thread besitzt eine Priorität, die aussagt, wie viel Rechenzeit ein Thread relativ zu anderen Threads erhält. Die Priorität ist eine Zahl zwischen Thread.MIN_PRIORITY (1) und Thread.MAX_PRIORITY (10). Durch den Wert kann der Scheduler erkennen, welchem Thread er den Vorzug geben soll, wenn mehrere Threads auf Rechenzeit warten. Bei seiner Initialisierung bekommt jeder Thread die Priorität des erzeugenden Threads. Normalerweise ist es die Priorität Thread.NORM_PRIORITY (5). Die Priorität kann durch Aufruf von setPriority() geändert und mit getPriority() abgefragt werden. Allerdings macht Java nur sehr schwache Aussagen über die Bedeutung und Auswirkung von Thread-Prioritäten.



class java.lang.  Thread  
implements Runnable

gp  final int getPriority()
Liefert die Priorität des Threads.
gp  final void setPriority( int newPriority )
Setzt die Priorität des Threads. Es ergibt eine IllegalArgumentException, wenn die Priorität nicht zwischen MIN_PRIORITY (1) und MAX_PRIORITY (10) liegt.

Beispiel   Wir geben dem Thread t die höchste Priorität.

t.setPriority( Thread.MAX_PRIORITY );


Galileo Computing

9.5.1 Threads hoher Priorität und das AWT  downtop

Werden Threads vom Betriebssystem verwaltet, hat es meist unerwünschte Auswirkungen, wenn man einem Thread die höchste Priorität zuweist. Der Rest des Programms, insbesondere seine grafische Oberfläche, wird sehr zäh reagieren. Dies liegt daran, dass für die übrigen Threads nicht mehr ausreichend Rechenzeit verbleibt. Wenn wir einem Thread eine niedrige Priorität zuweisen, dann kann ein höher priorisierter Thread ihm verfügbare Rechenzeit wegnehmen. Wollen wir einem Programmteil eine höhere Priorität zuweisen, dann ist es in der Regel nicht sinnvoll, seine Priorität hochzusetzen, sondern stattdessen die Priorität eines anderen Threads zu reduzieren. Dies macht sich beispielsweise bei Programmen mit einer Benutzerschnittstelle bemerkbar. Wir erwarten, dass das Programm unverzüglich auf Benutzereingaben reagiert. Daher sollte unser Hauptprogramm mit einer niedrigeren Priorität arbeiten als der Teil, der die Benutzeraktionen bearbeitet (normalerweise der AWT-Thread). Das Verzahnen von GUI-Code und Anwendung ist eine besondere Herausforderung, der wir uns im Zusammenhang mit grafischen Oberflächen noch stellen müssen.


Galileo Computing

9.5.2 Granularität und Vorrantoptop

Die zehn Prioritätsstufen garantieren nicht zwingend unterschiedliche Ausführungen. Obwohl anzunehmen ist, dass ein Thread mit der Priorität NORM_PRIORITY+1 häufiger Programmcode ausführt als ein Thread mit der Priorität NORM_PRIORITY, kann ein Betriebssystem dies anders implementieren. Nehmen wir an, die Plattform implementiert lediglich fünf Prioritätsstufen. 1 ist die niedrigste Stufe und 5 die höchste; die mittlere Stufe ist 3. Dann werden wahrscheinlich NORM_PRIORITY und NORM_PRIORITY+1 auf die Stufe 3 transformiert und haben demnach dieselbe Priorität. Wir können daraus eine Lehre ziehen: Auch bei unterschiedlichen Prioritäten können wir nicht erwarten, dass ein bestimmtes Programmstück zwingend schneller läuft. Zudem gibt es Betriebssysteme mit Schedulern, die keine Prioritäten unterstützen oder diese unerwartet interpretieren.





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


[Galileo Computing]

Galileo Press GmbH, Gartenstraße 24, 53229 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de