Threads erzeugen

[seux]

Moin,
wollte mal wissen, welcher Weg der gebräuchlicherere ist, um Threads zu erzeugen.

• Methode 1: Eine neue Klasse erzeugen und das Runnable Interface implementieren. Um den Thread zu starten folgt dann sowas wie

  Thread myThread = new Thread(new runnableClass());
  myThread.start();

• Methode 2: Eine neue Klasse erzeugen, die von Thread erbt und hier die run() Methode überschreiben. Der Thread wir dann auf diese Art gestartet

  Thread_Extended myThread = new Thread_Extened();
  myThread.start();

gruß
seux

 

[HimBromBeere]

Da gibt´s meines Wissens nach keine wirkliche Festlegung... wenn du eine freie Vererbung brauchst, würde ich zu Runnable raten (da du damit nur implementierst). Runnable hat halt nur den "Nachteil", dass es keine Thread#start()-Methode kennt (ist ja schließlich auch kein Thread).

 

[ireas]

Mir ist bisher nur die zweite Variante über den Weg gelaufen; auch mein Lehrbuch (Pepper) hat das mE. so gemacht.

 

[HimBromBeere]

Naja, die erste hat den Vorteil, dass die Klasse, die du an den Konstruktor von Thread übergibst noch eine Vererbung (extends) frei hat und du somit noch was anderes damit machen kannst als nur "run". Das allein ist aber natürlich kein Alles-oder-nichts-Kriterium.

 

[seux]

Runnable hat halt nur den "Nachteil", dass es keine Thread#start()-Methode kennt (ist ja schließlich auch kein Thread).

hmm, naja, ich kann ja alle Funktionen von Thread nicht nutzen. Wenn ich meinen Thread als SetDaemon(true) haben möchte, müsste ich das ebenfalls von außerhalb machen. Oder kann ich in der Klasse, die Runnable implementiert sowas schreiben wie (Pseudocode, hab grad hier kein Java drauf um nachzugucken, wie die Funktion nochmal heißt)

Thread.getCurrentThread().setDaemon(true);

?

 

[xehpuk]

Ja, das geht.

(Pseudocode, hab grad hier kein Java drauf um nachzugucken, wie die Funktion nochmal heißt)

Darf ich dir die Doku im Netz vorstellen? Tada! Thread#currentThread()

Die erste Variante ist eigentlich die sauberere (cooles Wort), aber ich verwende aus Faulheit die zweite, weil etwas weniger Tipparbeit.

 

[Lumaraf]

Ja, das geht.

[c]Thread.getCurrentThread().setDaemon(true);[/c] wird nicht funktionieren da die Methode setDaemon(boolean) nur aufgerufen werden darf solange der Thread noch nicht gestartet wurde.

 

[xehpuk]

Ah, es ging speziell um

setDaemon()

, okay.

Sehe da jetzt aber keinen Grund für das Extendieren von

Thread

. Soll das dann etwa so aussehen?

class Daemon extends Thread {
    {
        setDaemon(true);
    }

    @Override
    public void run() {
        // ...
    }
}

Da würde ich mir eher sowas schreiben:

static Thread createDaemon(final Runnable target) {
    final Thread t = new Thread(target);
    t.setDaemon(true);
    return t;
}

 

[seux]

[c]Thread.getCurrentThread().setDaemon(true);[/c] wird nicht funktionieren da die Methode setDaemon(boolean) nur aufgerufen werden darf solange der Thread noch nicht gestartet wurde.

Naja, wenn ich den Part in den Konstruktor der Runnable Klasse packe, ist der Thread ja eigl auch noch nicht gestartet.

Ich bin eher davon ausgegangen, dass ich das nicht nutzen darf, weil ich von der Runnable Klasse auch eine Instanz anlegen darf, ohne sie an einen Thread zu übergeben.

 

[xehpuk]

Der Thread existiert dann noch gar nicht, daher ist das wirklich nicht möglich.

 

[seux]

Okay, danke an alle schonmal für die Hilfe.

Aber ich hab noch ein paar Fragen zu Threads

• 1: Kann ich den Scheduler explizit darauf hinweisen, dass er nun einen anderen Thread starten soll.
• 2: Angenommen, ich hab mehrere Threads, die jeweils zugriff auf ein und dasselbe Objekt haben. Kann ich mit Hilfe eines weiteren Threads irgendwie herausfinden, ob das Objekt verändert wurde und von welchem Thread dies kam?

 

[HimBromBeere]

1. Keine Ahnung
2. Ich fürchte, das musst du selbst machen. Also innerhalb der run-Methode den aktuellen Thread merken und eine Variable isSet auf true setzen (damit du weißt, dass irgendwas an deinem Objekt verändert wurde).