Feststellen ob kein extra Thread läuft

[The_S]

Im zusammenhang mit diesem Thread http://www.java-forum.org/de/viewtopic.php?t=22432&highlight= hat sich ein neues Problem aufgetan. Ich habe eine kleine Suche programmiert, die mit Multithreading arbeitet (geht zumindest bei mir schneller, näheres in dem verlinktem Thread :wink: ) und für jeden neuen Ordner einen extra Thread öffnet um diesen zu druchlaufen. Jetzt ist würde ich gerne wissen, wie ich möglichst ohne Performanceeinbusen mein Hauptprogramm erst dann weiterlaufen lassen kann, wenn alle anderen Threads beendet sind.

 

[SnooP]

Kannst du im Hauptprogramm an der Stelle nicht einfach nen Thread.join() machen? Dann wartet es so lange, bis alle anderen Subthreads gestorben sind.

 

[The_S]

Warum kann ich in der public kein Thread.join() machen? Ist Thread static? Bin grad auf dem Sprung heim, deswegen ein wenig geistig abwesend :wink:

 

[Bleiglanz]

auf jeden Fall brings was, für Directories OHNE Subdirs keinen thread zu verbraten!

	public static void main(String[] args) {
		start = System.currentTimeMillis();
		searchMulti(new File("/tmp"), "test"); //$NON-NLS-1$ //$NON-NLS-2$
		Thread warter = new Thread(){
			public void run(){
				while(counter.get()>0){
					try {
						Thread.sleep(100);
					} catch (InterruptedException e) {
						// TODO Auto-generated catch block
						e.printStackTrace();
					}
				}
			}
		};
		warter.start();
		try {
			warter.join();
		} catch (InterruptedException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}

		System.out
				.println("searchMulti " + (System.currentTimeMillis() - start)); //$NON-NLS-1$ //$NON-NLS-2$
		System.out.println(trefferliste);
		trefferliste.clear();
		start = System.currentTimeMillis();
		searchSingle(new File("/tmp"), "test"); //$NON-NLS-1$ //$NON-NLS-2$
		System.out
				.println("searchSingle " + (System.currentTimeMillis() - start)); //$NON-NLS-1$ //$NON-NLS-2$
		System.out.println(trefferliste);

	}

	static Vector<File> trefferliste = new Vector<File>();

	static long start;

	static AtomicInteger counter = new AtomicInteger(0);

	static void searchMulti(final File dir, final String search) {
		File[] files = dir.listFiles();
		if (null != files) {
			for (File file : files) {
				if (file.getName().equalsIgnoreCase(search)) {
					trefferliste.addElement(file);
				}
				if (file.isDirectory()) {
					final File dirToScan = file;
					(new Thread(){
						public void run() {
							counter.incrementAndGet();
							try {
								searchMulti(dirToScan, search);
							} finally {
								counter.decrementAndGet();
							}
						}
					}).start();					
				}
			}
		}
	}

	static void searchSingle(final File dir, final String search) {
		File[] files = dir.listFiles();
		if (null != files) {
			for (File file : files) {
				if (file.getName().equalsIgnoreCase(search)) {
					trefferliste.addElement(file);
				}
				if (file.isDirectory()) {
					searchSingle(file, search);
				}
			}
		}
	}
}

das mit dem joinen ist wohl übel, weil ja ständig neue Threads losgetreten werden, man müsste dazu wohl buchführen

 

[Solour]

such ma nach Thread#getThreadGroup()
und dann müsstest du eben immer einen aus der group joinen bis die leer ist, oder eben selber die threads in nen vector packen wenn du sie startest und am ende alle joinen..

 

[SnooP]

Thread.join() ist static, wie alle anderen Methoden auch von Thread...
Wenn das Starten der Einzelthreads per rekursiver Methode im Hauptprogramm abläuft, könnte doch das join dort direkt nach dem Aufruf der Methode erfolgen - damit stellt man dann doch sicher, dass dort erst weitergemacht wird, wenn alle Ergebnisse eingesammelt wurden, ansonsten kann man das ja halt nicht sicher wissen und läuft gefahr mit Daten zu operieren, die noch nicht vollständig sind...

das mit den leeren Verzeichnissen sollte aber schonmal Sinnhaftig sein

 

[Bleiglanz]

Wenn das Starten der Einzelthreads per rekursiver Methode im Hauptprogramm abläuft, könnte doch das join dort direkt nach dem Aufruf der Methode erfolgen - damit stellt man dann doch sicher, dass dort erst weitergemacht wird, wenn alle Ergebnisse eingesammelt wurden

ja aber das wär ja das gleiche wie singleThreaded!

joinen geht IMHO bei dem Problem nicht, weil ja am laufenden Band Threads erzeugt werden, die müsste man sich alle merken und dann am ende alle joinen (aber wozu?)

auch die neuen Sachen wie Futures und die CyclicBarrier usw. verlangen dass man vorher weiss, auf wieviele Threads man warten will

aber mal was grundsätzliches:

auf einer 1CPU Normalomaschine ist die Multithreaded Version IMMER langsamer (und verbrät auch ganz schön Speicher)

sinnvoll wär das z.B. wenn man riesige Verzeichnisse durchsuchen will und nebenbei eine Anzeige in der GUI auffüllen ("Responsiveness"), aber dazu reicht prinzipiell erstmal ein Thread

und wenn ein directory bloss 10-100 Einträge hat, dann ist so ein Thread wahrscheinlich in seiner ersten Zeitscheibe sofort fertig und der Overhead möglicherweise nicht gerechtfertigt...

 

[Solour]

aber mal was grundsätzliches:

auf einer 1CPU Normalomaschine ist die Multithreaded Version IMMER langsamer (und verbrät auch ganz schön Speicher)

werden mehrere java-threads überhaupt unter z.B. windows auf meherer prozessoren verteilt? oder ist das dann ein prozess?
unter unix (hab ich mal gehört) wird für jeden thread ein prozess getartet (stimmt das?)

insgesamt hört sich das für mich auch eher nach etwas an, was man besser iterativ und ohne threads macht

 

[SnooP]

Das Quoting ist etwas kaputt ... - aber ich hatte jetzt einfach mal vermutet, dass Multiprozessoren dabei besser agieren können - immerhin ist es Aufgabe des OS die Threads an den Prozessor zu reichen - und anstatt nach dem normalen Round-Robin-Prinzip vorzugehen, könnte jetzt auch einfach ein weiterer Prozessor berücksichtigt werden...
Ich hab auch sowieso nicht ganz geblickt warum der OP das überhaupt so haben wollte ...

Das mit Prozessen und Threads unter Unix halte ich für ein Märchen ... ein Thread wurde ja gerade eingeführt, weil es nicht soviel kostet einen solchen neu zu erstellen... Prozess bedeutet immer erheblich mehr Schritte die ausgeführt werden müssen... von daher wäre es sinnfrei, wenn Unix(e) generell jeden Thread in einen Prozess kapseln würde.

 

[Bleiglanz]

ob mehrere Pozessoren genutzt werden und ob ggf. leichtgewichtige threads verwendet werden hängt einfach von der JVM - Version - Hersteller - Betreibssystem ab, kann man nicht pauschal sagen

 

[The_S]

Hab jetzt ne Übergangslösung, statt alles in nem Vector zu speichern, speicher ich es gleich in eine JList so das der User die ergebnisse angezeigt bekommt. Aber irgendwie anders wäre natürlich schöner ...