16.11.2013 Aufrufe

Programmieren in Java - HostFiXX.de

Programmieren in Java - HostFiXX.de

Programmieren in Java - HostFiXX.de

MEHR ANZEIGEN
WENIGER ANZEIGEN

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.

<strong>Programmieren</strong> <strong>in</strong> <strong>Java</strong><br />

Anwendung_1<br />

Betriebssystem<br />

Anwendung_2<br />

<strong>Java</strong>_VM_1<br />

<strong>Java</strong>_VM_2<br />

VM Prozess_1 lok. Variable<br />

Prozess_2 lok. Variable<br />

glob.<br />

Variable Prozess_3 lok. Variable<br />

Abb. Betriebssystem - VM<br />

Die Abbildung <strong>de</strong>r <strong>Java</strong>-Prozesse auf BS-Prozesse hängt von <strong>de</strong>r Implementierung<br />

<strong>de</strong>r VM ab. Es gibt Implementierungen<br />

- die das Schedul<strong>in</strong>g <strong>de</strong>r VM-Prozesse übernehmen<br />

- die das Schedul<strong>in</strong>g <strong>de</strong>m darunterliegen<strong>de</strong>n BS überlassen<br />

"schedul<strong>in</strong>g strategies". Threads benötigen für ihre Ausführung e<strong>in</strong>en Prozessor.<br />

Viele <strong>Java</strong>-Anwendungen unterstützen nur e<strong>in</strong>en Prozessor. Bei nur e<strong>in</strong>em<br />

Prozessor kann nur e<strong>in</strong> Thread aktiv se<strong>in</strong>. Der Thread wird <strong>de</strong>m Prozessor zugeteilt.<br />

Man spricht <strong>in</strong> diesem Zusammenhang von Schedul<strong>in</strong>g. Die Zuteilungsstrategie<br />

bee<strong>in</strong>flusst das Verhalten <strong>de</strong>s Systems bei mehreren Threads. Folgen<strong>de</strong> Zustän<strong>de</strong><br />

e<strong>in</strong>es Thread können unterschie<strong>de</strong>n wer<strong>de</strong>n:<br />

- Initialzustand<br />

Der Thread wur<strong>de</strong> erzeugt, führt aber die noch ke<strong>in</strong>e Metho<strong>de</strong> aus, d.h. start() wur<strong>de</strong> noch nicht<br />

aufgerufen.<br />

- Lauffähig<br />

E<strong>in</strong> Thread geht vom Initialzustand mit start() <strong>in</strong> <strong>de</strong>n Zustand "lauffähig" über.<br />

- Aktiv<br />

E<strong>in</strong> Thread wird aktiv, wenn er von <strong>de</strong>r VM aus <strong>de</strong>r Menge <strong>de</strong>r lauffähigen Threads ausgewählt wird.<br />

In diesem Zustand führt <strong>de</strong>r Thread tatsächlich Co<strong>de</strong> aus. Der Thread wird von <strong>de</strong>r VM dazu entwe<strong>de</strong>r<br />

<strong>in</strong> <strong>de</strong>n Zustand lauffähig zurückgesetzt o<strong>de</strong>r er kommt <strong>in</strong> <strong>de</strong>n Zustand "blockiert".<br />

- Blockiert<br />

E<strong>in</strong> Thread ist blockiert, wenn er auf <strong>de</strong>n exklusiven Zugriff auf e<strong>in</strong>es bei synchronized<br />

angegebenen Objekts o<strong>de</strong>r auf das Ergebnis mit wait() wartet.<br />

Ist <strong>de</strong>r Thread blockiert, dann geht er <strong>in</strong> <strong>de</strong>n Zustand "lauffähig" über, falls e<strong>in</strong> an<strong>de</strong>rer Thread mit<br />

e<strong>in</strong>em notify() o<strong>de</strong>r notifyAll() das Ergebnis mel<strong>de</strong>t und daraufh<strong>in</strong> die VM <strong>de</strong>s blockierten<br />

Threads auswählt.<br />

- Endzustand.<br />

Der Thread ist <strong>in</strong> se<strong>in</strong>em Endzustand, falls run() ausgeführt wur<strong>de</strong> o<strong>de</strong>r mit e<strong>in</strong>er Ausnahme<br />

been<strong>de</strong>t wur<strong>de</strong>.<br />

105

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!