Java Schulung (Java 2 Java Development Kit 5 / 6)

Transkript

1 4. Threads und nebenläufige Programmierung 4.1 Prozesse und Threads Moderne Betriebssysteme geben Benutzer die Illusion, verschiedene Programm würden gleichzeitig ausgeführt (Multitasking) Tatsächlich jedoch Quasiparallelität durch Scheduler (verzahnte Verarbeitung von Prozessen) Bei Mehrprozessormaschinen tatsächlich parallele Abarbeitung Bei modernen Betriebssystemen gehört zu jedem Prozess mindestens ein Thread (Ausführungsstrang), der Programmcode ausführt In Java auch multithreaded Software möglich, wenn OS keine Threads direkt verwendet (in diesem Fall simuliert JVM die Parallelität) Wie parallele Programme die Geschwindigkeit steigern können Zunächst nicht ersichtlich, wie 1-Prozessor-System durch nebenläufige Abarbeitung beschleunigt werden kann Betrachtet man ein Programm, das eine Folge von Anweisungen ausführt (z.b. Visualisieren eines Datenbank-Reports) Die Schritte sind dann z.b. 1. Baue ein Fenster auf. 2. Öffne die Datenbank vom Netz-Server, und lies die Datensätze. 3. Analysiere die Daten, und visualisiere den Fortschritt. 4. Öffne die Datei, und schreibe den erstellten Report. Auf dem ersten Blick typisches sequenzielles Programm; kann aber durch geschickte Parallelisierung beschleunigt werden Überlegung, welche Schritte gleichzeitig ausgeführt werden können: o Das Öffnen von Fenster, Ausgabedatei und Datenbank kann parallel geschehen. o Das Lesen neuer Datensätze und das Analysieren alter Daten kann gleichzeitig erfolgen. o Alte analysierte Werte können während der neuen Analyse in die Datei geschrieben werden. Parallelisierbare Ressourcen Wenn Operationen tatsächlich parallel durchgeführt, enormer Leistungszuwachs zu verzeichnen (bei 1-Prozessor-Systemen) Bei den gleichzeitig auszuführenden Aufgaben handelt es sich um unterschiedliche Ressourcen Wenn die grafische Oberfläche das Fenster aufbaut, braucht sie dazu Rechenzeit, parallel kann Datei geöffnet werden, wobei weniger Prozessorleistung gefragt ist, da die vergleichsweise träge Festplatte angesprochen wird Öffnen der Datenbank wird auf den Datenbank-Server im Netzwerk abgewälzt (Geschwindigkeit hängt von der Belastung des Servers und des Netzes ab) Wenn anschließend Daten gelesen werden, muss Verbindung zum Datenbank-Server natürlich stehen. Daher sollte man zuerst die Verbindung aufbauen Marcel Wieczorek S e i t e

2 In diesem Beispiel ist durch hohe Parallelisierung Leistungssteigerung möglich, da die bei langsamen Operationen anfallenden Wartezeiten genutzt werden können Ressource Belastung Hauptspeicherzugriffe Dateioperationen Prozessor Festplatte Datenbankzugriff Nebenläufigkeit muss gut geplant werden Server, Netzwerkverbindung Nur wenn verzahnte Aktivitäten unterschiedliche Ressourcen verwenden, resultiert daraus auf Einprozessorsystemen ein Geschwindigkeitsvorteil 4.2 Threads erzeugen Threads über die Schnittstelle Runnable implementieren Damit Thread weiß, was er ausführen soll, muss man ihm Anweisungsfolgen geben (diese werden in einem Befehlsobjekt vom Typ Runnable verpackt und dem Thread übergeben) Wird der Thread gestartet, arbeitet er die Programmzeilen aus dem Befehlsobjekt parallel zum restlichen Programmcode ab Die Schnittstelle Runnable ist schmal und schreibt nur eine run()-methode vor Beispiel: zwei Threads, wobei einer zwanzigmal das aktuelle Datum und die Uhrzeit ausgibt und der andere einfach eine Zahl Beispiel: CounterCommand.java package de.assona.threads.first; /** mwieczorek */ class CounterCommand implements Runnable { for (int i = 0; i < 20; i++) System.out.println(i); Threads über Runnable starten Um Thread nun als solchen zu starten, reicht es nicht aus, run()-methode aufzurufen Würden man dies tun, wäre nichts nebenläufig, sondern man würde einfach eine Methode sequenziell ausführen Damit Programmcode parallel zur Applikation läuft, muss man Thread-Objekt mit dem Runnable verbinden und dann den Thread explizit starten Dazu wird Konstruktor der Klasse Thread Referenz auf das Runnable-Objekt übergeben und start() aufgerufen Nachdem start() für den Thread eine Ablaufumgebung geschaffen hat, ruft es intern selbstständig die Methode run() genau einmal auf Läuft der Thread schon, löst zweiter Aufruf der start()-methode IllegalThreadStateException aus Marcel Wieczorek S e i t e

3 Beispiel: FirstThread.java public static void main(string[] args) { Thread t1 = new Thread(new DateCommand()); t1.start(); Thread t2 = new Thread(new CounterCommand()); t2.start(); Beispiel-Ausgabe: Tue Jun 1010:53:47 CEST Tue Jun 1010:53:47 CEST Verzahnung beider Threads deutlich zu erkennen Kommt durch unterschiedliche Laufzeiten zustande, die für Datums- und Zeitausgabe notwendig sind Die Klasse Thread erweitern Klasse Thread implementiert selbst das Interface Runnable und implementiert die run()- Methode mit leerem Programmcode Will man eigene parallele Aktivitäten programmieren, kann man auch die Klasse Thread erweitern Beispiel: DateThread.java public class DateThread extends Thread { for (int i = 0; i < 20; i++) System.out.println(new java.util.date()); Aufruf DateThread dt = new DateThread(); dt.start(); // new DateThread().start(); Konstruktor muss kein Runnable-Exemplar mehr übergeben werden (es genügt der Aufruf der Methode start()) Marcel Wieczorek S e i t e

4 Erweitern von Thread oder Implementieren von Runnable? Vorteil Nachteil Ableiten von Thread (extends Thread) Programmcode in run() kann die Methoden der Klasse Thread nutzen. Da es in Java keine Mehrfachvererbung gibt, kann die Klasse nur von Thread erben. Implementieren von Runnable (implements Runnable) Klasse kann von anderer problemspezifischer Klasse erben. Kann sich nur mit Umwegen selbst starten (Threadmethoden nur über Umwege nutzbar) Beste Idee wäre, Runnable-Objekte zu bauen, die dann dem Thread übergeben werden Befehlsobjekte dieser Art sind recht flexibel, da die einfachen Runnable-Objekte leicht übergeben und sogar von Threads aus einem Thread-Pool ausgeführt werden können 4.3 Die Zustände eines Threads Bei Thread-Exemplar gibt es verschiedene Zustände festzustellen Zustand Nicht erzeugt Laufend Wartend Beendet Erläuterung Lebenslauf eines Thread-Objekts beginnt mit new, doch befindet er sich damit noch nicht im Zustand ausführend Durch start() gelangt Thread in den Zustand»ausführbar«beziehungsweise»laufend«; Zustand kann sich ändern, wenn anderer Thread zur Ausführung gelangt und dann dem aktuellen Thread den Prozessor entzieht (vormals laufender Thread kommt in den Zustand nicht laufend, bis der Scheduler ihm wieder Rechenzeit zuordnet) Zustand wird mittels spezieller Synchronisationstechniken oder Ein- /Ausgabefunktionen erreicht Thread verweilt in einem Wartezustand Nachdem die Aktivität des Thread-Objekts beendet wurde, kann es nicht mehr aktiviert werden und ist tot, also beendet Zustand über Thread.State Zustand des Threads zeigt die Methode getstate() (liefert Objekt vom Typ der Aufzählung Thread.State) NEW RUNNABLE BLOCKED WAITING Neuer Thread, noch nicht gestartet Läuft in der JVM Wartet auf einen MonitorLock, wenn er etwa einen synchronized Block betreten möchte Wartet etwa auf ein notify() TIMED_WAITING Wartet etwa in einem sleep() TERMINATED Ausführung beendet Marcel Wieczorek S e i t e

5 Das Ende eines Threads Es gibt Threads, die dauernd laufen, weil sie zum Beispiel Server-Funktionen implementieren Andere führen einmalig eine Operation aus und sind danach beendet Allgemein ist ein Thread beendet, wenn eine der folgenden Bedingungen zutrifft o Die run()-methode wurde ohne Fehler beendet (Endlosschleife würde potenziell nie endenden Thread bilden) o In der run()-methode tritt eine RuntimeException auf, die die Methode beendet (beendet weder die anderen Threads noch die JVM als Ganzes) o Der Thread wurde von außen abgebrochen (dazu dient problematische Methode stop(), von deren Verwendung abgeraten wird und die auch veraltet ist) o Die virtuelle Maschine wird beendet und nimmt alle Threads mit ins Grab Einen Thread mit interrupt() beenden Enthält run()-methode Endlosschleife (z.b. Serveranwendung), muss Thread von außen zur Kapitulation gezwungen werden Man bittet ihn, seine Arbeit aufzugeben (Thread lauscht periodisch, ob jemand von Außen Abbruchwunsch geäußert hat) Die Methoden interrupt() und isinterrupted() Methode interrupt() setzt von außen in einem Thread-Objekt ein internes Flag, das dann in der run()-methode durch isinterrupted() periodisch abgefragt werden kann Folgendes Programm soll jede halbe Sekunde eine Meldung auf dem Bildschirm ausgeben Nach zwei Sekunden wird der Unterbrechungswunsch mit interrupt() gemeldet Auf dieses Signal achtet die sonst unendlich laufende Schleife und bricht ab Beispiel: ThreadusInterruptus.java public static void main(string[] args) throws InterruptedException { ThreadusInterruptus ti = new ThreadusInterruptus(); ti.start(); Thread.sleep(2000); ti.interrupt(); System.out.println("Es gibt ein Leben vor dem Tod. "); while (!isinterrupted()) { System.out.println("Und er läuft und er läuft und er läuft"); try { Thread.sleep(500); catch (InterruptedException e) { interrupt(); System.out.println("Unterbrechung in sleep()"); System.out.println("Das Ende"); Marcel Wieczorek S e i t e

6 run()-methode im Thread so implementiert, dass Schleife genau dann verlassen wird, wenn isinterrupted() den Wert true ergibt, also von außen die interrupt()-methode für dieses Thread-Exemplar aufgerufen wurde Genau dies geschieht in der main()-methode Stünde interrupt() im catch-block nicht, würde vermutlich nicht funktionieren Wenn Ausgabe nur jede halbe Sekunde stattfindet, befindet sich der Thread fast die gesamte Zeit über in der Schlafmethode sleep() Also wird vermutlich der interrupt() den Thread gerade beim Schlafen stören Dann wird sleep() durch InterruptedException unterbrochen, und der catch-behandler fängt die Ausnahme ein Durch Unterbrechung wird das interne Flag zurückgesetzt, sodass isinterrupted() meint, die Unterbrechung habe gar nicht stattgefunden interrupt() muss erneut aufgerufen werden, da das Abbruch-Flag neu gesetzt werden muss und isinterrupted() das Ende bestimmen kann neben sleep() löschen auch die Methoden join() und wait() durch die InterruptedException das Flag Der stop() von außen Wenn Thread nicht auf interrupt() hört, aber aus irgendwelchen Gründen dringend beendet werden muss, können wir die veraltete Methode stop() einsetzen Bietet keine Möglichkeit, dass Thread Zustand konsistent verlässt Thread kann nur noch sein Testament in Form eines ThreadDeath-Objekts anzeigen Das ThreadDeath-Objekt Immer Wenn Thread durch stop() zum Ende kommen soll, löst JVM ThreadDeath-Ausnahme aus, die Thread letztendlich beendet ThreadDeath ist Unterklasse von Error, das wiederum von Throwable abgeleitet ist, sodass ThreadDeath mit einem try-catch-block abgefangen werden kann Wenn man ThreadDeath auffängt, kann man noch auf den Tod reagieren und Aufräumarbeiten erlauben Man sollte aber nicht vergessen, anschließend das aufgefangene ThreadDeath-Objekt wieder auszulösen, weil der Thread sonst nicht beendet wird Beispiel: ThreadStopRevovery.java public static void main(string[] args) throws InterruptedException { ThreadStopRecovery tsr = new ThreadStopRecovery(); tsr.start(); Thread.sleep(1); tsr.stop(); try { while (true) System.out.println("I Like To Move It."); catch (ThreadDeath td) { System.out.println("Das Leben ist nicht tot zu kriegen."); throw td; Marcel Wieczorek S e i t e

7 Auf das Ende Warten mit join() Will man Aufgaben auf mehrere Threads verteilen, kommt der Zeitpunkt, an dem Ergebnisse eingesammelt werden Resultate können allerdings erst zusammengebracht werden, wenn alle Threads mit Ausführung fertig sind Zum Warten gibt es mehrere Strategien o Zunächst lässt sich mit Callable arbeiten, um dann mit get() synchron auf das Ende zu warten o Arbeitet man mit Runnable, kann ein Thread keine direkten Ergebnisse wie eine Funktion nach außen geben, weil die run()-methode den Ergebnistyp void hat o Da nebenläufiger Thread zudem asynchron arbeitet, weiß auch nicht, wann das Ergebnis zu erwarten ist Übertragung von Werten ist kein Problem Hier können Klassenvariablen und auch Objektvariablen helfen, denn über sie kann man kommunizieren Was fehlt, ist die Möglichkeit, auf das Ende der Aktivität eines Thread warten zu können Das funktioniert mit der Methode join() In folgendem Beispiel legt Thread t Ergebnis in Variable result ab Beispiel: JoinTheThread.java public static void main(string[] args) throws InterruptedException { JoinerThread t = new JoinerThread(); t.start(); t.join(); System.out.println(t.result); Beispiel: JoinerThread.java public class JoinerThread extends Thread { public int result; result = 1; Ohne Zeile t.join() wird mit der Ausgabe nicht gewartet, bis JoinerThread fertig ist und daher hat die Variable result noch den Wert 0 Threads schlafen Manchmal notwendig, Thread bestimmt Zeit lang anzuhalten; dazu lassen sich zwei Methoden nutzen Klassenmethode: Thread.sleep() Objektmethode: sleep() auf einem TimeUnit-Objekt Beide beziehen sich auf den ausführenden Thread; bei TimeUnit Zeiteinheiten besser sichtbar Marcel Wieczorek S e i t e

8 Beispiel: SleepThread.java package de.assona.threads.sleep; import java.util.concurrent.timeunit; /** mwieczorek */ public class SleepThread extends Thread { public int result; try { //Thread.sleep(2000); TimeUnit.SECONDS.sleep(2); System.out.println("Zeit ist um."); catch (InterruptedException e) { e.printstacktrace(); /** args InterruptedException */ public static void main(string[] args) throws InterruptedException { SleepThread st = new SleepThread(); st.start(); Beispiel: Eine Zeituhr 4.4 Arbeit niederlegen und wieder aufnehmen final void suspend() Hat man die Möglichkeit, auf den Thread zuzugreifen (checkaccess() regelt dies wieder), und der Thread lebt, wird er so lange eingefroren (schlafen gelegt), bis resume() aufgerufen wird final void resume() Weckt einen durch suspend() lahm gelegten Thread wieder auf, der dann wieder arbeiten kann beide Methode veraltet und ähnlich problematisch wie stop() 4.5 Priorität Jeder Thread verfügt über eine Priorität, die aussagt, wie viel Rechenzeit ein Thread relativ zu anderen Threads erhält 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 Initialisierung bekommt jeder Thread die Priorität des erzeugenden Threads. Normalerweise ist es die Priorität Thread.NORM_PRIORITY (5) Das Betriebssystem (oder die JVM) nimmt die Threads immer entsprechend der Priorität aus der Warteschlange heraus (daher Prioritätswarteschlange) Die Priorität kann durch Aufruf von setpriority() geändert und mit getpriority() abgefragt werden Marcel Wieczorek S e i t e

9 4.6 Dämonen Thread würde bei Endlosschleife weiterlaufen, auch wenn Hauptapplikation beendet ist (nicht immer beabsichtigt) Dazu erhält Thread spezielle Kennung (wird als Dämon gekennzeichnet) Wenn Hauptprogramm beendet ist und Laufzeitumgebung erkennt, dass kein normaler Thread sondern nur noch ein Daemon läuft, wird dieser beendet Beispiel: DaemonThread.java package de.assona.threads.daemon; /** mwieczorek */ public class DaemonThread extends Thread { public DaemonThread() { setdaemon(true); while (true) System.out.println("Lauf, Thread, lauf"); public static void main(string[] args) { new DaemonThread().start(); Ohne setdaemon(true) würde Thread ewig weiterlaufen 4.7 Kooperative Threads Neben sleep() gibt es weitere Methode, um kooperative Threads zu programmieren: die Methode yield() funktioniert etwas anders als sleep(), da hier nicht nach Ablauf der genannten Millisekunden zum Thread zurückgekehrt wird, sondern yield() den Thread bezüglich seiner Priorität wieder in die Thread-Warteschlange des Systems einordnet Einfach ausgedrückt, sagt yield() der Thread-Verwaltung:»Ich setzte diese Runde aus und mache weiter, wenn ich das nächste Mal dran bin.«4.8 Synchronisation und kritische Abschnitte Eigenständiges Leben der Thread oftmals problematisch für die anderen Gemeinsam genutzte Daten Über statische Variablen oder auch gemeinsam genutzte Datenstruktur können Threads Daten austauschen Marcel Wieczorek S e i t e

10 Probleme beim gemeinsamen Zugriff und kritische Abschnitte Da Threads eigene Daten Verwalten (lokale Variablen, Stack), kommen sie sich nicht in die Quere Auch wenn Threads gmeinsame Daten nur lesen, gibt es kein Problem Gemeinsamer Schreibzugriff ist problematisch Ursprung der Probleme bei Arbeitsweise der Threads (Scheduler unterbricht zu unbekanntem Zeitpunkt Abarbeitung des Threads) Kritische Abschnitte: zusammenhängende Programmblöcke, die nicht unterbrochen werden dürfen und besonders geschützt werden müssen Nicht kritische Abschnitte: z.b. Methoden, die keine Objekteigenschaften verändern Abschnitte mit synchronized schützen Blöcke oder Methoden werden mit Modifier synchronized markiert Betretender Thread setzt bei Objekt-Methoden den Monitor des this-objekts und bei statischen Methoden den Lock des dazugehörigen Class-Objekts Versucht Thread A synchronisierte Methode aufzurufen, die ein anderer Thread B vorher betreten hat, muss der nachfolgende Thread B so lange warten, bis die Methode wieder frei ist (wenn erster Thread Methode verlässt) Beim Verlassen der Methode (oder einer Ausnahme), gibt JVM automatisch den Lock frei Dauer des Locks also an Länge des Methodenaufrufs gekoppelt (kann Parallelität einschränken) Monitore Betritt Programm eine synchronisierte Methode, bekommt es den Monitor des aufrufenden Objekts Wenn diese Methode eine andere aufruft, die am gleichen Objekt synchronisiert ist, kann sie sofort eintreten und muss nicht warten Diese Eigenschaft heißt reentrant (Ohne diese Möglichkeit würde Rekursion nicht funktionieren) Statisch synchronisierte Blöcke private static final Object o = new Object(); static void staticfoo() { synchronized (o) { //... Vor- und Nachteile von synchronisierten Blöcken und Methoden Vorteile Nachteile Schutz des kritischen Bereiches vor Schwer zu debuggen bei threadlastigen Eingriffen durch anderen Thread Programmen Allgemein langsamer als nicht synchronisierte Blöcke / Methoden Gefahr von DeadLocks Marcel Wieczorek S e i t e

11 Deadlocks Deadlock kommt vor, wenn Thread A eine Ressource belegt, die Thread B haben möchte Thread B belegt aber eine Ressource, die Thread A haben möchte Somit können beide nicht vor und nicht zurück (dauernder Wartezustand) Beispiel: Deadlocks package de.assona.threads.deadlocks; import java.util.concurrent.timeunit; import java.util.concurrent.locks.*; /** mwieczorek */ public class DeadLock { private static Lock lock1 = new ReentrantLock(), lock2 = new ReentrantLock(); private static class T1 extends Thread { lock1.lock(); System.out.println("T1: Lock auf lock1 bekommen"); try { TimeUnit.SECONDS.sleep(1); catch (InterruptedException e) { lock2.lock(); System.out.println("T1: Lock auf lock2 bekommen"); lock2.unlock(); lock1.unlock(); private static class T2 extends Thread { lock2.lock(); System.out.println("T2: Lock auf lock2 bekommen"); lock1.lock(); System.out.println("T2: Lock auf lock1 bekommen"); lock1.unlock(); lock2.unlock(); public static void main(string[] args) { new T1().start(); new T2().start(); Marcel Wieczorek S e i t e

12 4.9 Synchronisation über Warten und Benachrichtigen Mit einem Lock-Objekt wie ReentrantLock können zwecks Benachrichtigung Condition- Objekte abgeleitet werden. Dazu dient die Funktion newcondition() Warten mit await() und Aufwecken mit signal() Damit das Warten und Benachrichtigen funktioniert, kommunizieren die Parteien über ein gemeinsames Condition-Objekt, das vom Lock erfragt wird Condition condition = lock.newcondition(); void await() throws InterruptedException Wartet auf ein Signal, oder die Methode wird unterbrochen void signal() Weckt einen wartenden Thread auf Vor der Condition kommt ein Lock Lock-Objekt dient nicht nur dazu, Condition zu liefern Methoden await() und signal() können nur dann aufgerufen werden, wenn vorher ein lock() den Signal-Block exklusiv sperrt Ohne lock() kommt es zur Laufzeit zu einer java.lang.illegalmonitorstateexception Normalerweise könnte nach await() kein anderer Thread über einen durch das gleiche Lock- Objekt gesperrte Abschnitt signal() aufrufen Lösung besteht darin, dass await() den Monitor freigibt, den der Thread hält und den Thread so lange sperrt, bis z.b. von einem anderen Thread das signal() kommt Mehrere Wartende und signalall() Es kann durchaus vorkommen, dass mehrere Threads in einer Warteposition an demselben Objekt sind und aufgeweckt werden wollen signal() wählt dann aus der Liste der Wartenden einen Thread aus und gibt ihm das Signal Sollten alle Wartenden einen Hinweis bekommen, lässt sich signalall() verwenden Beispiel: Erzeuger-Verbraucher-Programm Day_6 Package: de.assona.threads.example 4.10 Gruppen von Threads in einer Thread-Gruppe Wird Thread erzeugt, gehört dieser automatisch zu einer Gruppe, die durch ein ThreadGroup-Objekt repräsentiert wird (Verwaltung ist Aufgabe der Laufzeitumgebung) Gruppenzugehörigkeit bekommt jeder Thread bei seiner Erzeugung zugeteilt (man kann sie beeinflussen) Entweder wird Gruppe beim Erzeugen mit angegeben oder erzeugter Thread kommt in die gleiche Gruppe wie der erzeugende Thread-Gruppen baumartig strukturiert (Wurzel ist die Gruppe main) Thread-Verwaltung wird erleichtert (alle Threads einer Gruppe können gestoppt werden oder Priorität kann verändert werden) Etwas über die aktuelle Thread-Gruppe herausfinden Day_6: de.assona.threads.showthreadsinmain.java Marcel Wieczorek S e i t e

13 Threads in einer Thread-Gruppe anlegen ThreadGroup tg = new ThreadGroup("sync"); Thread t1 = new Thread(tg, "threadname"); 4.11 Die Klassen Timer und TimerTask Scheduler arbeitet Programmstücke nach einer festen Zeitspanne oder zu einem fixen Zeitpunkt einmal oder wiederholt ab TimerTask ist eine Klasse, die Runnable implementiert (in run()-methode dann zeitgesteuerte Ausführung) Übung In dieser Übung sollen die Bremer Stadtmusikanten als Multithreading-Java-Programm implementiert werden. Es wird davon ausgegangen, dass die einzelnen Tiere über eine Art Megaphon ein für sie typisches Geräusch erzeugen können (d.h. die Tiere können nur mit Hilfe des Megaphons ein genug lautes Geräusch erzeugen). Zudem steht nur ein einziges solches Megaphon für alle Tiere zur Verfügung. 1. Jedes Tier soll nach jedem zehnten Mal Laut geben für 1 Sekunde schlafen gehen, ohne das Megaphon aus der Hand zu geben. 2. Jedes Tier soll nach jedem fünften Mal in einen Wartezustand gehen. Zuvor wird das Megaphon freigegeben und alle Tiere, welche sich ebenfalls in diesem Wartezustand befinden, werden aus dem Wartezustand geweckt und über das Freiwerden des Megaphons benachrichtigt. 3. Jedes Tier soll nach jedem tausendsten Mal vor lauter Laut geben in einen apathischen Zustand versinken, ohne das Megaphon herzugeben (suspend). Marcel Wieczorek S e i t e