Dagegen spricht, dass die Methode [japi]BlockingQueue#take()[/japi] blockiert. Dadurch würde die Schleife in Zeile 20 der Klasse B „hängenbleiben“. Folglich wird die running Variable nicht geprüft. Durch einen Interrupt kann take() unterbrochen werden. Wenn der Thread einen Interrupt bekommt, kann man auch mit der Terminierung der Schleife reagieren.
Folglich ist die Variable running einfach überflüssig. Und überflüssige Variablen gehören weg
was dann an diesen speziellen Fall der Verwendung einer API-Methode, die mit Interruptet arbeitet, ankommt,
das muss ja nicht immer so sein
allgemein hat man die Wahl,
alles zu Interrupted bezieht sich aus gewisser Sichtweise auch nur auf einen intern schon vorhandenen boolean,
einen eigenen zusätzlich zu wählen ist aber häufiges Vorgehen, wobei häufig nicht immer richtig sein muss…,
denkbar und bekannt auf jeden Fall, durchaus als Stil zu bezeichnen
@SlaterB : welchen Ansatz findest du denn besser: den Thread extern zu “interrupten” oder mit einer quit()-Methode den Interrupt innerhalb der Klasse B auszulösen? Oder hättest du einen vollkommen anderen Ansatz gewählt?
take scheint zu warten, richtig? Das wollte ich eigentlich nicht, deshalb testete ich auch, ob die Queue gefüllt ist. Natürlich macht es in der Beispielklasse keinen Sinn, nicht zu warten, aber wenn andere, regelmäßige Dinge zu machen wären, schon.
remove scheint nur eine Exception zu werfen, wenn die Queue leer ist. Was ich ja vorher abprüfe.
guter Punkt, die quit()-Methode ist klar zu empfehlen, deutlicher,
überhaupt mehr Interface-Gedanke, von der Thread-Klasse und deren eingebaute Funktionialität wegkommen,
der Aufrufer muss gar nicht wissen um welche konkrete Klasse es sich handelt, dass das Interrupt-System betroffen ist,
Fach-Methode quit(), Rest intern
von interrupt() an sich kommt man hier sicherlich nicht weg, wenn BlockingQueue diese einsetzt,
an sich bin ich auch sonst eher Fan von eigenen booleans
Ich könnte das Thema natürlich als gelöst markieren, aber eigentlich ist die Diskussion dafür gerade zu interessant! :joyous:
Das hätte ich jetzt auch so gesehen. Zumal der Nutzer der Klasse B dann nur die Referenz auf B vorzuhalten braucht und nicht zusätzlich noch eine Referenz auf den Thread.
@Crian : oben bei der Beschreibung des Interfaces [japi]BlockingQueue[/japi] (einfach dem Link folgen) steht eine Übersicht. Es gibt auch Methoden, die einen konfigurierbaren Timeout haben ([japi]BlockingQueue#poll()[/japi] z. B.).
Ja, hab ich schon gesehen. Nachdem ich dort etwas gelesen habe, hab ich mich - jetzt losgelöst von A und B - für eine [japi]ConcurrentLinkedQueue[/japi] entschieden und in der Threadklasse ganz genau unterschieden (und dokumentiert), welche Methoden in welchem Thread laufen.