Multithreading

[dayaftereh]

Hallo,
ich bin gerade an einem Programm welches Dateien konvertieren soll. Ich möchte das jetzt Multithreading machen.ich habe eine Liste mit 1-1000 Dateien diese will ich jetzt auf 1-4 Threads aufteilen. Die Threads verarbeiten dann diese Dateien. Die Frage ist jetzt wie kann ich diese Liste am besten auf x Threads aufteilen. Ein erster Entwurf sieht folgendermaßen aus:

	private List<File> files = null;
	private List<Thread> threads = null;
	...
	private void runThreads(int therads) {		
		int stepps = files.size() / therads;
				
		if(stepps < 1){
			stepps = 1;
		}
		
		for (int start = 0; start < files.size(); start = start + stepps) {

			int end = stepps + start;
			if (start + stepps >= files.size()) {
				end = files.size();
			}

			
			xThread t = new xThread(start, end,files);
			t.start();
			threads.add(t);
		}
	}

die Klasse xThread Soll nur als Platzhalter dienen und bekommt den Start und Ende seiner Range und die Liste mit,um dann die Dateien zu konvertieren. Was Natürlich hier passiert ist, das die Aufteilung auf die Threas sehr unterschiedlich sind und zwar der letzte bekommt manchmal weniger als alle anderen.

Eine zweite Idee ist das jedem xTherad Einzelnen die Dateien hinzuzufügen und den Rest dann auf die Threads aufzuteilen und die xThreas nach der Aufteilung zu starten. Natürlich hätte jeder Thread Seine eigene Dateiliste.hat jemand von euch eine gute Idee?

Danke schonmal
LG

 

[Michael...]

Ich würde die Liste jetzt nicht fix aufteilen, sondern die Dateien nach und nach einem neu erzeugten Thread zur Abarbeitung übergeben, über einen Controller der die Threads verwaltet könnte man dann steuern, dass nur x Threads gleichzeitig laufen.

 

[dayaftereh]

Du meinst über eine Threadpool mit FIFO prinzip! ach ne idee! nur dan müssten immer alle Threads auf die Liste zugreifen! dasheißt ja wenn gerade ein Thread aus der Liste zieht, dan müssen alle anderen warten?

 

[FArt]

Das muss man (und sollte man) heute nicht mehr selber machen: ExecutorService (Java 2 Platform SE 5.0)

 

[dayaftereh]

Gut das Löst aber immer noch nicht das Proplem der Aufteilung der DateiListe?

 

[Empire Phoenix]

einfach eine synchronzied funktion die die threads wennse mit eienr datei fertig sind aufrufen um eine neue zugeweisen zu bekommen.

 

[FArt]

Ganz einfach: über die Liste iterieren und für jeden Eintrag ein Runnable in den Executor stopfen. Die Skalierung übernimmt man über die Konfiguration des Executors, z.B. des ThreadPoolExecutor (Java 2 Platform SE 5.0)

 

[ice-breaker]

Werden die Files denn von der Platte gelesen?
Wenn ja immer am ganzen stück oder nur soviel wie gerade gebraucht wird?

 

[dayaftereh]

Danke schonmal für eure Hilfe, konnte soweit Alles um setzen.
wenn ich ein ExecutorService nehme und für jedes File eine Runnable erzeuge und im ExecutorService execute. Wer das nicht bei 1000 Files zu viel für den ExecutorService ???ich meine für die Liste vom ExecutorService ! Also wenn man es übertreiben würde können's auch 10.000 Files Sein.

 

[ice-breaker]

ich weiß zwar nicht was du genau machst (weil du mir auf meine Fragen nicht geantwortet hast), aber sollten die Files von der Platte gelesen werden, dauert höchstwahrscheinlich das Lesen der Daten länger als die Abarbeitung oder?

Edit: Der Executor hat doch eine einstellbare max. Queue, ich kann mir durchaus vorstellen, dass er bei erreichen der max. Länge, wenn du immernoch etwas einfügen möchtest, solange blocked bis wieder Platz ist, so wird verhindert, dass du nicht einfach immer mehr Aufträge in die Schlange hängst
Müsstet mal im JavaDoc nachlesen ob er sich wirklich so verhält, bin mir aber relativ sicher.

 

[Marco13]

Ein Ansatz wäre auch, alle Files in einfach in eine Queue zu legen, und die von den Threads abholen zu lassen... kann aber auch sein, dass das mit einem ExecutorService eleganter (d.h. intern, versteckt, "automatisch") geht.

 

[FArt]

@themenstarter
Nicht so viele Verschwörungstheorien ausdenken.
Du kannst den Service frei konfigurieren und erweitern. Wenn dir das Defaultverhalten nicht taugt, dann benutze ihn einfach mit einer anderen Art Queue, z.B. eine, ihre Warteliste persistent hält... das schont den Arbeitsspeicher und ist NUR dann sinnvoll, wenn sehr viele Aufträge in Kurzer Zeit eintrudeln, deren Abarbeitung aber relativ lange dauert.
Vielleicht ist aber asynchrone Verarbeitung in denem Fall gar nicht sinnvoll? Vielleicht soltest du Datensatz für Datensatz lesen und verarbeiten?

 

[Gast2]

aber sollten die Files von der Platte gelesen werden, dauert höchstwahrscheinlich das Lesen der Daten länger als die Abarbeitung oder?

Vielleicht ist aber asynchrone Verarbeitung in denem Fall gar nicht sinnvoll? Vielleicht soltest du Datensatz für Datensatz lesen und verarbeiten?

das wäre eine Überlegung Wert ... denn das langsamste im Rechner bleibt nunmal die Festplatte ... solange sich die Technik nicht grundlegend ändert, wird das auch die nächste Jahrzente so bleiben

hand, mogel

 

[SlaterB]

gerade weil die Platte so langsam ist, lohnt sich doch überhaupt erst Nebenläufigkeit?
bei 100% Java-Code bringen Threads abgesehen von Ordnung gar nix, an Geschwindigkeit kann es nur langsamer werden,

nur wenn man auf die lahme Festplatte warten muss, kann es Sinn machen, gleich mehrere Dinge gleichzeitig abzufragen,
mehr oder weniger Verarbeitung und (mehrfaches) warten parallel zu schalten,

ob der Festplattenzugriff durch die Mehrfachnutzung noch langsamer wird als vorher, ist ne andere Frage,
wenn alle Dateien auf der Festplatte fragmentiert sind und sowieso ständig überall gelesen werden muss,
wirds mit mehreren Anfragen evtl. eher effizienter als langsamer

aber genaues weiß ich dazu nicht

-----

edit:
vielleicht sind Threads am nützlichsten, wenn viel Java-Code abzuarbeiten ist,
sich also gegenüber der langsamen Festplattenarbeit die Waage hält

 

[dayaftereh]

Hey,

Danke für eure ideen, also ich will Bilder verkleinern und Skalieren! also neu ziechnen, und ein paar Filte drüberlaufen lassen! und das Wollte ich in den Threads machen! Mir ist schon klar das immer nur ein THread von der Platte lesen kann! aber wenn die Bilder dan im speicher sind! dan lohnt es sich schon mehrere Threads zu haben oder sehe ich das Jetzt hier falsch?

 

[SlaterB]

genau andersrum aus meiner Sicht:
alles was im Speicher ist kann Java nur einmal bearbeiten, da reicht ein Thread, der bringt die CPU auf 100%
(von Mehrfach-Prozessor abgesehen, das ist ein anderes Thema, vielleicht aber sinnvoller als mein Punkt)
nur bei Festplattenzugriff kann man mehrere Dinge gleichzeitig schedulen

vergleiche das mit dem bekannten Thema kochen
wenn die Lebensmittel erstmal zu Hause auf der Küchenplatte liegen (Arbeitsspeicher)
und nur ein Herd (CPU) da ist, reicht ein Koch, mehrere müssten sich nur abwechseln und könnten zwischendurch
nur Daumen drehen (von Nebentätigkeiten wie Kartoffel schälen abstrahiert)

Einkaufen (Festplatte) dauert dagegen sehr lange,
da kann man ruhig mehrere Laufburschen gleichzeitig losschicken,
die je eine benötigte Zutat(enmenge) holen (eine Datei)

kommt natürlich darauf an, wie schnell der Koch ist relativ zum Zutatenholen,
wenn er in 5 Min. kocht und das Holen 30 Min. dauert, dann sollten es viele Laufburschen sein,

wenn das Kochen 30 Min. dauert und das Holen nur 5 Min., dann reicht ein Laufbursche,
der nur rechtzeitig genug losgeschickt werden muss (2 Threads),
immer noch besser als wenn der Koch selber einkaufen muss (1 Thread)

mehrere Köche kann man immer noch nicht einsetzen, da nur ein Herd (CPU) da ist und jeder
Koch den die ganze Zeit belegt,

 

[Gast2]

gerade weil die Platte so langsam ist, lohnt sich doch überhaupt erst Nebenläufigkeit?

eben nicht ... weil der Lesekopf auf der Platte immer umherspringt um alle Threads gleich zu behandeln ... damit geht die Datenrate in den Keller ... es ist nun mal nur eine Festplatte (RAID zählt nicht) ... die Algorithmen zum lesen auf der Festplatte sind zwar hoch optimiert ... aber bei asynchronen Zugriffen gibt es weiterhin Probleme

vielleicht sind Threads am nützlichsten, wenn viel Java-Code abzuarbeiten ist,
sich also gegenüber der langsamen Festplattenarbeit die Waage hält

dann macht es wieder Sinn ... das sieht man allerdings schon bei einem Thread ... wenn beim Laden und Verarbeiten ein Kern nahezu zu 100% ausgelastet ist, dann lohnt sich ein weiterer Thread bzw. Kern