Threads Timer

[eLwoodianer]

Hallo zusammen,

Ich sitze gerade an einer Programmieraufgabe und bin mir bei der Realisierung eines Timers unsicher.

Aufgabenstellung:

Gegeben sei ein Ringpuffer, […] besitzt die Methoden put und get, um einen Wert im Puffer abzulegen bzw. aus dem Puffer auszulesen. put und get können von verschiedenen Threads aufgerufen werden. Der Zugriff auf den gemeinsamen Puffer ist ein kritischer Bereich. […] Schreiben Sie ein Testprogramm, mit 3 Erzeuger‐ und 2 Verbraucher‐Threads, die unterschiedlich schnell sind. Die Erzeuger‐Threads schreiben Zufallszahlen […] die Verbraucher‐ Threads holen Werte aus dem Puffer und geben sie auf dem Bildschirm aus. Das Programm soll nach einer vorgegebenen Zeit terminieren. Dazu benötigen Sie einen Timer‐Thread. Sobald die Laufzeit – in Minuten – eingestellt ist, läuft die Zeit quasi rückwärts. Nach Ablauf der Zeit müssen die noch aktiven Erzeuger‐ und Verbraucher‐Threads sicher beendet werden.

Folgende Lösungsansätze sind mir dazu eingefallen:

• Man startet einfach einen Thread, lässt ihn die angegebene Zeit "schlafen" und wartet im Hauptprogramm bis er fertig ist um anschließend alle Erzeuger und Verbraucher zu unterbrechen.
• Man könnte aber auch einem Timer-Thread starten. Ihm den Auftrag geben nach der angegeben Zeit ein TimerTask auszuführen, in dem alle Threads unterbrochen werden. Der Klasse InterruptThreads (extends TimerTask) könnte man im Konstruktor die zu unterbrechenden Threads als Array übergeben. (Um es flexibel zu gestalten.)

Meine Erfahrung mit Timern geht gegen Null. Deshalb meine Frage: Was für ein Lösungsansatz bietet sich an, gibt es vielleicht noch andere Herangehensweisen?

Viele Dank
eL

 

[tagedieb]

Meine Lösungsvorschlag ist den Timer zu verwenden. Es macht keinen Sinn das selber zu implementieren.
Der Timertask sollte aber die Threads nicht selber beenden sondern nur ein Flag (boolan running) setzen und die Consumer- und Providerthreads prüfen regelmässig auf dieses Flag. (Einen Thread mit interrupt zu beenden ist alles andere als sicher).

Als Basis für den Ringpuffer würd ich eine BlockingQueue empfehlen, damit kannst du dir die ganze synchronization sparen. Ausserdem kannst du zum Auslesen die Methode

poll(time, unit)

verwenden, damit der Thread nicht ewigs wartet.

 

[eLwoodianer]

Ich versteh nicht ganz, was du mit "(Einen Thread mit interrupt zu beenden ist alles andere als sicher)" meinst.
Ich dachte an folgendes Prinzip... Im Hauptprogramm:

Thread producer1 = new Thread(ProducerJob);

, in einer von TimerTask abgeleitetet Klasse:

producer1.interrupt;

und in der Klasse ProducerJob:

 run { while(!isInterrupted) { ... } }

Das ist doch gänige Praxis und sicher ... oder täusch ich mich da ???:L

Das mit der BlockingQueue ist gut zu wissen, allerdings in diesem Fall nicht gewünscht, da wir uns mit der Synchronisation auseinander setzen sollen.

eL

 

[tagedieb]

Ich versteh nicht ganz, was du mit "(Einen Thread mit interrupt zu beenden ist alles andere als sicher)" meinst.
Ich dachte an folgendes Prinzip... Im Hauptprogramm:

Thread producer1 = new Thread(ProducerJob);

, in einer von TimerTask abgeleitetet Klasse:

producer1.interrupt;

und in der Klasse ProducerJob:

 run { while(!isInterrupted) { ... } }

Das ist doch gänige Praxis und sicher ... oder täusch ich mich da ???:L

Das mit der BlockingQueue ist gut zu wissen, allerdings in diesem Fall nicht gewünscht, da wir uns mit der Synchronisation auseinander setzen sollen.

eL

Nein, dies ist weder gängige Praxis noch sicher.

Interrupt killt sozusagen den Thread. Dies ist nicht gerade als sicher zu bezeichnen.
Ein Thread beendet sich sicher, wenn er das Ende der

run()

Methode erreicht.


Dies kann man z.B. via Flag erreichen. In jedem durchgang wird der Flag geprueft und falls 'false' die Methode beendet. Von aussen kann man dann via

thread.setRunning(false)

den Thread stoppen.

boolean running = true;
public void run() {
    while(running) {
        ...
    }
}

public voic setRunning(boolean running) {
    this.running = running;
}

thread.interrupt()

sollte man nur in Ausnahmesituationen benutzen, da Exceptions nicht zur Applikationslogik gehören sondern Ausnahmen behandeln. Wenn du aber mit synchronized arbeiten musst solltest du die

wait(long timeout)

verwenden, damit die Threads nicht endlos blockieren (genau dafür braucht man nämlich dann interrupt())

 

[eLwoodianer]

[...] Durch Aufruf von

interrupt

wird ein Flag gesetzt, das eine Unterbrechungsanforderung signalisiert. Durch Aufruf von

isInterrupted

kann der Thread feststellen, ob das Abbruchflag gesetzt wurde [...]

Entweder steh ich auf dem Schlauch oder deine Aussage passt nicht zu der Aussage im Buch. Weiter steht dort auch, dass die beiden Methoden dafür da sind um genau das zu machen was du in deinem Beispiel beschreibst.

Ich hab das gerade mit

run { while(!isInterrupted) { ... } }

getestet und der Thread läuft sauber bis zum Ende der run()-Methode durch, nachdem er mit Thread.interrupt() unterbrochen wurde.

 

[tagedieb]

Gratuliere, dann hast du das Ziel erreicht!!

Programierung ist zum Teil auch Geschmacksache. Auch die Leute von (Sun/Java) sind nicht ueber alle Zweifel erhaben und koennen umstrittene Loesungen entwickeln.

Das gleiche gilt fuer Professoren, welche Buecher scheiben. Inhaltlich zwar korrekt, aber das heist nicht, dass man die auch in der Praxis verwenden sollte. Viele von Ihnen schaffen es auch nach Jahren nicht sich in ihren Beispielen an die Java Namingconventions zu halten

 

[eLwoodianer]

Ich denk ich hab verstanden auf was du hinaus willst und auch die Problematik mit

interrupt()

. Wieder was gelernt heute.