Threads und trotzdem keine Nebenläufigkeit

[Weisswurst]

Hi!

Ich habe einen Swing Dialog, mit einer Liste und einem Datamodel.
Beim Aufbau des Dialogs werden zwei Threads gestartet.
Der eine besorgt von einigen Rechnern über Netzwerk Informationen, der andere Pollt an einer anderen Stelle
nach einer Triggerdatei.

Momentan sieht die Sache so aus:
- Dialog wird aufgebaut (Dialogelemente platziert)
- Threads werden gestartet
- Dialog wird sichtbar gemacht

Über log4j Ausgaben kann ich jetzt sehen, dass beide Threads laufen und Abwechselnd Meldungen rausschreiben.
Zur Info: Der Datensammelthread wartet per Timer erst noch ein Weilchen. Solange der wartet kann ich den Dialog verwenden (rumklicken) und der Monitorthread pollt regelmssig.

Sobald aber der Sammelthread loslegt geht gar nix mehr. Der Dialog is eingefrohren und der Pollthread schreibt keine Logs mehr raus. Dafür tut der Datensammler wofür er gedacht ist. Sobald er fertig ist und sein Timer wieder läuft kann ich auch wieder in dem Dialog rumklicken und sehe Logs vom Poller.

Ich kann heute leider nicht auf den Quellcode zugreifen, sonnst würde ich posten wie die Threads aussehen.
Soweit ich mich erinnere werden die Threads über die Methode "Start" angestossen und haben in "Run" eine
Endlosschleife laufen.

Letztendlich ist meine Frage wie ich es hinkriege, dass der Dialog immer benutzbar bleibt. Das der eine Thread den anderen blockiert ist im konkreten Fall nicht dramatisch.

Danke schonmal!

Gruß
Wurst

 

[SlaterB]

mein Java-Programm produziert grüne Kaugummis,
ich habe zwar keinen Quellcode aber frage schonmal, woran das liegt..

fahre testweise die Arbeit des Sammelthreads auf 0 durch immer mehr und schließlich nur noch Thread.sleep()s,
wenn trotzdem alles blockiert ist, dann läuft da wohl was NICHT nebenläufig

 

[Niki]

Du musst den anderen Threads Zeit geben, dass sie etwas machen können. Wenn ein Thread immer 100% der CPU frisst, können die anderen natürlich nichts machen. Bau einfach in jedem Schleifenintervall ein Thread.sleep(10) oder ein Thread.yield() ein. Das sollte das Problem eigentlich lösen.

 

[CK]

schau mal bei SwingUtilities und invoke later damit die Oberfläche bedienbar bleibt. Fressen aber dein Threads die gesammte CPU Last bringt das auch nix mehr.

 

[Weisswurst]

mein Java-Programm produziert grüne Kaugummis,
ich habe zwar keinen Quellcode aber frage schonmal, woran das liegt..

Ich sagte ich habe heute keinen Zugriff auf den Quellcode...
Der liegt auf dem SVN und ich habe hier keine lokale Kopie im Zugriff.

fahre testweise die Arbeit des Sammelthreads auf 0 durch immer mehr und schließlich nur noch Thread.sleep()s,
wenn trotzdem alles blockiert ist, dann läuft da wohl was NICHT nebenläufig

Tatsächlich ist der Sammelthread hauptsächlich mit warten auf Antworten von den ganzen Rechnern beschäftigt, die er abklappert.

Gehe ich recht in der Annahme, dass ich so lange mit Sleep rumexperimentieren muss, bis die Threads laufen und mein Dialog trotzdem noch flüssig bedienbar bleibt?

Das Problem ist, dass manche Rechner 20 bis 30 Sekunden brauchen bis sie Antworten. Abgefragt werden die Infos über ein XML File, dass per UNC geholt wird. An der Stelle an der, der UNC Zugriff erfolgt würde dann also mein Dialog auf jeden Fall still stehen?

oder ein Thread.yield() ein. Das sollte das Problem eigentlich lösen.

In der Doku steht, "Causes the currently executing thread object to temporarily pause and allow other threads to execute." Kann man das so interpretieren, dass der Thread dann automatisch zu gegebener Zeit weiter macht
oder muss ich den wieder aufwecken?

 

[byte]

Gehe ich recht in der Annahme, dass ich so lange mit Sleep rumexperimentieren muss, bis die Threads laufen und mein Dialog trotzdem noch flüssig bedienbar bleibt?

Nein.

 

[Niki]

Ein Thread kann sich in unterschieldichen Status befinden:
Blocked, Waiting, Sleeping
Runnable
Running

Runnable heißt, er wäre zwar bereit um etwas zu tun, hat aber vom Scheduler noch keine Zeit zum Laufen bekommen. Running heißt, er läuft tatsächlich. Das heißt also, dass der Scheduler entscheidet, welcher Thread tatsächlich gerade Zeit bekommt. Du kannst es eben nur mit yield bzw. sleep ein wenig steuern. Oder du spielst dich mit wait und notify. Da musst du dann halt aufpassen, dass du in keinen Deadlock rennst.

 

[Weisswurst]

Genau, ich dachte eigentlich, dass der Scheduler meinen Datensammler von Zeit zu Zeit von der CPU holen würde und mal meinen Dialog ran lassen würde.

Ich werde morgen mal mit sleep und yield spielen. Blöd nur, dass ich damit vermutlich die 20 Sekunden locks nicht in den Griff bekomme in denen die JVM wartet bis der andere Rechner endlich die Datei rausrückt...

Auf jeden Fall vielen Dank für die Tipps!

 

[Niki]

Naja, wenn ein Thread auf irgend etwas wartet müsste er sich ja im blocked-Modus befinden. Daher sollten eigentlich eh andere Threads Zeit bekommen. Zumindest ist das glaub ich bei I/O Operationen so.

 

[Weisswurst]

Genau, weil eigentlich inzwischen eigentlich eh das Betriebssystem rennt um die Datei zu organisieren.
Aber vlt. gilt das nur wenn man auf dem lokalen Rechner I/O Operationen anstösst.

 

[byte]

Ohne den Code zu sehen, kann man eh nur raten, was bei Dir schief läuft. Das ist sinnlos!

 

[Roland]

Ich finde "Rumraten" gar nicht so schlecht... Das macht einen Thread erst interessant und das meine ich jetzt nicht ironisch.
Jeder der ein ähnliches Problem hat und zufällig auf den Thread hier stößt kriegt doch schonmal einige Möglichkeiten aufgezeigt worans liegen könnte bzw. in welche Richtung er suchen muss.

Wenn Weisswurst sofort Code präsentiert hätte, dann hätte es evtl. nen knappen Hinweis auf den Fehler gegeben und Schluss.

Ich als hauptsächlicher Mitleser finde sowas schon interessant

 

[Weisswurst]

Sehe das ähnlich wie Roland.
Wenn ich in rl mit nem anderen Programmierer über ein Problem rede, dann heißts auch
schau mal ob du XY hast.

Ich kann aber auch verstehen warum sich Slater und byto aufregen. Klar ist eine definitive Lösung kanns ohne QC nicht geben. Ich hätte natürlich auch die Frage erst morgen stellen können, wenn ich wieder dran bin...
Hätte damit aber den heutigen Tag in der Sache ungenutzt verstreichen lassen.

 

[Weisswurst]

So, endlich komme ich mal wieder zu diesem Thema.

Ich habe nun ein paar Sleeps gesetzt und es ist tatsächlich so, dass meine Liste im Hauptdialog neu sortiert wird, sobald der Thread in die Sleep Methode läuft. Ich habe jetzt aber immernoch das Problem, dass in den Methoden
control.read...IntoDModel über UNC (Netzwerk) auf ein File zugegriffen wird.

File dummy = new File("\\\\" + ipserver+ "\\d$\\...)

Während dieses Zugriffs, der wie gesagt bei manchen Rechnern 20 bis 30 Sekunden dauern kann, hängt meine Gui, weil der Thread wartet und nicht für andere Threads platz macht.

Ist jetzt die einizigste Möglichkeit meine Control Klasse in der eigentlich die ganze Anwendunslogik ist in nen Thread (Swingworker???) zu verpacken? Und und dann die Dateien in der doInBackground Methode zu lesen und dann über die done Methode den aufrufenden Thread zu benachrichtigen, dass die Datei da ist. dass der dann die nächste
read... Methode aufruft?

public void run()
	{
		
		timer = new Timer(360000, this);
		timer.setInitialDelay(1);
		timer.start();
		
		do
		{
						
		}while(true);
	}

//Wird vom Timerevent gestartet
private void updateServerData()
	{
		
		DataModel dm = new DataModel();
		List<? extends SortKey> keyList = sorter.getSortKeys();
		int selRow = table.getSelectedRow();
		int selCol = table.getSelectedColumn();
		
		try
		{
			control.readServerListFromDB();
			this.sleep(10);
			control.readServerListIntoDModel(dm);
			this.sleep(10);
			control.readSession1IntoDModel(dm); 
			this.sleep(10);
			control.readVersion1IntoDModel(dm);
			
			
		} catch (DBErrorException e)...