Threads Viele Aufrufe aus Thread, komisches Verhalten

[Mappenz]

Hallo,

ich habe gerade ein kleines Thread-Experiment gemacht. Das Ergebnis kann ich mir nicht erklären.
Thread Version 1:

private class testThread extends Thread {
		private JFish jFish = new JFish();
		private int serial;
		private int number = 1;
		private int direction = 1;
		private int speed = 6;
		
		public testThread(Models model) {
			serial = model.serial();
		}

		public testThread(Models model, int number) {
			this.serial = model.serial();
			this.number = number;
		}

		@Override
		public void run() {
				jFish.setMotorEx(serial, number, direction, speed);
		}
	}

Thread Version 2

private class testThread extends Thread {
		private JFish jFish = new JFish();
		private int serial;
		private int number = 1;
		private int direction = 1;
		private int speed = 6;
		
		public testThread(Models model) {
			serial = model.serial();
		}

		public testThread(Models model, int number) {
			this.serial = model.serial();
			this.number = number;
		}

		@Override
		public void run() {
                       while(true) {
				jFish.setMotorEx(serial, number, direction, speed);
                       }
		}
	}

Der einzige Unterschied ist die while-Schleife in run().

setMotorEx:

public synchronized int setMotorEx(int serial, int number, int direction, int speed) {
         ...
	  result = new JavaFish().jrSetMotorEx(ifm.iHandle(serial), number, direction, speed);
          ...
	}

ifm.iHandle(serial), hier geht was schief:

	public synchronized int iHandle(int serial) throws InvalidIHandleException {
		int iHandle = jrError;	
		Pair cpair = new Pair(serial, iHandle);
		if(pairs.contains(cpair)) {
			iHandle = pairs.get(pairs.indexOf(cpair)).iHandle;
		} else  {
			//close interfaces and remove, if necessary
			if(pairs.size() >= SIZE){
				iHandle = pairs.getFirst().iHandle;
				int i = new JavaFish().jrCloseInterface(iHandle); //new instance necessary, because JavaFish instances might expire.
				pairs.removeFirst();
			}
			iHandle =  new JavaFish().jrOpenInterfaceUSB(ftDCB, serial);//new instance necessary, because JavaFish instances might expire HIER PASSIERT DER FEHLER
			iHandleCheck(iHandle);
			pairs.addLast(new Pair(serial, iHandle));
		} 
		return iHandle;
	}

Threads erzeugen und laufen lassen:

	public synchronized void run8Plus1Threads() throws InterruptedException {
		new testThread(Models.BAND0x11).start();
		new testThread(Models.BAND0x13).start();
		new testThread(Models.BAND0x21).start();
		new testThread(Models.BAND0x23).start();
		new testThread(Models.BAND0x3).start();
		new testThread(Models.BAND0x5).start();
		new testThread(Models.STAMP0x17, 2).start();
		new testThread(Models.STAMP0x27, 2).start();
		wait(5000);
		Thread thread = new testThread(Models.LINE0x29, 2);
		thread.start();
		wait(50000);
	}

JavaFish kann bis zu 8 Interfaces zu Modelen öffnen und ist ganz Empfindlich gegenüber fehlerhaften Aufrufen seiner member. Der Thread Version 1 tut was ich erwartet habe: Es laufen 8 Modelle und wenn das Neunte Laufen will tut es das auf und eins der ersten Acht steht.

Bei Thread Version 2 gibt es von Anfang an Fehler an der markierten Stelle in iHandle(serial).

Da iHandle(serial) synchronized ist wundere ich mich, dass es für JavaFish Aufrufe aus dieser Methode herraus einen Unterschied zwischen den Thread Versionen gibt.

Kann mir jemand den Unterschied erkären?

Viele Grüße
Michael

 

[SlaterB]

was ist denn die Fehlermeldung?
geht es darum dass 9 Fische statt 8 erstellt werden?

logge doch mit System.out.println() genau was welcher Thread wann macht, wieviele Einträge in der Liste sind,
wie groß ist eigentlich SIZE?

du schreibst der Fehler kommt bei
> jrOpenInterfaceUSB(ftDCB, serial);

wenn du den ersten Thread loggst, kommen dann als Meldungen z.B.
"erfolgreichen neuen Fisch erstellt, Size Liste = 1";
"erfolgreichen neuen Fisch erstellt, Size Liste = 2";
...
"erfolgreichen neuen Fisch erstellt, Size Liste = 7";
"erfolgreichen neuen Fisch erstellt, Size Liste = 8";
?

und beim zweiten Thread
"erfolgreichen neuen Fisch erstellt, Size Liste = 1";
"erfolgreichen neuen Fisch erstellt, Size Liste = 2";
...
"erfolgreichen neuen Fisch erstellt, Size Liste = 7";
[Fehler]
?

das wäre verwunderlich, aber so läufts wohl kaum,
auch beim zweiten Thread sollten 8 funktionieren, vielleicht gibts beim Versuch des 9. ein Problem
(ruhig auch vor der Anforderung eine Log-Ausgabe)

willst du das durch die contains-Abfrage auf die Liste verhindern? das darf man ruhig alles auch in Worte fassen,
vielleicht funktioniert das contains für Pair nicht, ist die equals-Methode für diese Klasse korrekt überschrieben?

edit:
allerdings sollte da ja noch das close/ remove funktionieren..
übrigens ganz schön gemein, falls ein Thread gerade mit dem Interface arbeitet, während ein andere willkürlich (auf das erste in der Liste) close() aufruft

 

[Michael...]

Da müsste man wohl Code sehen in dem die Zusammenhänge klarer werden. Was für Fehler treten denn auf? Fehlermeldungen? Ist es überhaupt relevant, dass die Methoden synchronized sind, wenn jeder Thread sein eigenes JFish Objekt besitzt? ...

 

[Mappenz]

hmm, das ist so schwer zu erklären ohne all zu sehr auszuschweifen.

Size ist 8, mehr als 8 interfaces macht JavaFish nicht auf. Pairs wird auch nicht größer als 8.

iHandle() mit Ausgaben:

	public synchronized int iHandle(int serial) throws InvalidIHandleException {
		//TODO interfaces are not to be closed if they are in use, implement a waiting queue or a message system to deal with this situation
		int iHandle = jrError;	
		Pair cpair = new Pair(serial, iHandle);
		if(pairs.contains(cpair)) {
			iHandle = pairs.get(pairs.indexOf(cpair)).iHandle;
		} else  {
			//close interfaces and remove, if necessary
			if(pairs.size() >= SIZE){
				iHandle = pairs.getFirst().iHandle;
				int i = new JavaFish().jrCloseInterface(iHandle); //new instance necessary, because JavaFish instances might expire
				pairs.removeFirst();
				System.out.println("Altes Interface geschlossen: " + i);
			}
			iHandle =  new JavaFish().jrOpenInterfaceUSB(ftDCB, serial);//new instance necessary, because JavaFish instances might expire
			iHandleCheck(iHandle);
			pairs.addLast(new Pair(serial, iHandle));
			System.out.println("Neues Interface geöffnet: Nr: " + iHandle + " für " + Integer.toHexString(serial));
		} 
		System.out.println(Integer.toHexString(serial) + " erhält Interface " + iHandle + " pairs.size(): " + pairs.size());
		return iHandle;
	}

Output für Threads ohne while

Neues Interface geöffnet: Nr: 0 für 11
11 erhält Interface 0 pairs.size(): 1
Neues Interface geöffnet: Nr: 1 für 13
13 erhält Interface 1 pairs.size(): 2
Neues Interface geöffnet: Nr: 2 für 3
3 erhält Interface 2 pairs.size(): 3
Neues Interface geöffnet: Nr: 3 für 21
21 erhält Interface 3 pairs.size(): 4
Neues Interface geöffnet: Nr: 4 für 5
5 erhält Interface 4 pairs.size(): 5
Neues Interface geöffnet: Nr: 5 für 23
23 erhält Interface 5 pairs.size(): 6
Neues Interface geöffnet: Nr: 6 für 17
17 erhält Interface 6 pairs.size(): 7
Neues Interface geöffnet: Nr: 7 für 27
27 erhält Interface 7 pairs.size(): 8
Altes Interface geschlossen: 0
Neues Interface geöffnet: Nr: 0 für 29
29 erhält Interface 0 pairs.size(): 8

Mit der while-Schleife gibts viele Ausgaben ich kürze das etwas:

...
...
...
17 erhält Interface 5 pairs.size(): 8
17 erhält Interface 5 pairs.size(): 8
17 erhält Interface 5 pairs.size(): 8
17 erhält Interface 5 pairs.size(): 8
17 erhält Interface 5 pairs.size(): 8
17 erhält Interface 5 pairs.size(): 8
5 erhält Interface 6 pairs.size(): 8
...
5 erhält Interface 6 pairs.size(): 8
13 erhält Interface 0 pairs.size(): 8
...
13 erhält Interface 0 pairs.size(): 8
13 erhält Interface 0 pairs.size(): 8
3 erhält Interface 3 pairs.size(): 8
...
3 erhält Interface 3 pairs.size(): 8
13 erhält Interface 0 pairs.size(): 8
...
13 erhält Interface 0 pairs.size(): 8
Altes Interface geschlossen: -536870911
de.fzi.se.prozessteuerung.JFish.InvalidIHandleException
5 erhält Interface 6 pairs.size(): 7
...
5 erhält Interface 6 pairs.size(): 7
5 erhält Interface 6 pairs.size(): 7
5 erhält Interface 6 pairs.size(): 7
17 erhält Interface 5 pairs.size(): 7
17 erhält Interface 5 pairs.size(): 7
17 erhält Interface 5 pairs.size(): 7
17 erhält Interface 5 pairs.size(): 7
17 erhält Interface 5 pairs.size(): 7
17 erhält Interface 5 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
27 erhält Interface 7 pairs.size(): 7
...
27 erhält Interface 7 pairs.size(): 7
	at de.fzi.se.prozessteuerung.JFish.InterfaceManager.iHandleCheck(InterfaceManager.java:96)
	at de.fzi.se.prozessteuerung.JFish.InterfaceManager.iHandle(InterfaceManager.java:58)
	at de.fzi.se.prozessteuerung.JFish.JFish.setMotorEx(JFish.java:56)
	at de.fzi.se.prozessteuerung.JFish.JFishTest$testThread.run(JFishTest.java:39)
27 erhält Interface 7 pairs.size(): 7
...
27 erhält Interface 7 pairs.size(): 7
21 erhält Interface 2 pairs.size(): 7
...
21 erhält Interface 2 pairs.size(): 7
23 erhält Interface 4 pairs.size(): 7
23 erhält Interface 4 pairs.size(): 7
...
23 erhält Interface 4 pairs.size(): 7
21 erhält Interface 2 pairs.size(): 7
...
21 erhält Interface 2 pairs.size(): 7
21 erhält Interface 2 pairs.size(): 7
27 erhält Interface 7 pairs.size(): 7
...
27 erhält Interface 7 pairs.size(): 7
27 erhält Interface 7 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
11 erhält Interface 1 pairs.size(): 7
de.fzi.se.prozessteuerung.JFish.InvalidIHandleException
	at de.fzi.se.prozessteuerung.JFish.InterfaceManager.iHandleCheck(InterfaceManager.java:96)
	at de.fzi.se.prozessteuerung.JFish.InterfaceManager.iHandle(InterfaceManager.java:58)
	at de.fzi.se.prozessteuerung.JFish.JFish.setMotorEx(JFish.java:56)
	at de.fzi.se.prozessteuerung.JFish.JFishTest$testThread.run(JFishTest.java:39)
17 erhält Interface 5 pairs.size(): 7
...
17 erhält Interface 5 pairs.size(): 7
5 erhält Interface 6 pairs.size(): 7
5 erhält Interface 6 pairs.size(): 7
...
5 erhält Interface 6 pairs.size(): 7
de.fzi.se.prozessteuerung.JFish.InvalidIHandleException
	at de.fzi.se.prozessteuerung.JFish.InterfaceManager.iHandleCheck(InterfaceManager.java:96)
	at de.fzi.se.prozessteuerung.JFish.InterfaceManager.iHandle(InterfaceManager.java:58)
	at de.fzi.se.prozessteuerung.JFish.JFish.setMotorEx(JFish.java:56)
	at de.fzi.se.prozessteuerung.JFish.JFishTest$testThread.run(JFishTest.java:39)
3 erhält Interface 3 pairs.size(): 7
...
17 erhält Interface 5 pairs.size(): 7

-536870911 ist jrError aus JavaFish. Mit der contains abfrage möchte ich verhindern, dass ein offenes Interface nochmal geöffnet wird. Sonst könnte ich das Interface nicht mehr benutzen und das Model wäre nicht mal mehr zu stoppen.

Du kannst sehen, dass das close nicht funktioniert. Das Model hört zwar auf zu laufen, aber wenn diese Fehlermeldung erscheint ist das gewöhnlich nicht mehr verfügbar. Es wird aber auch nicht mehr verteilt und ist schon aus der Liste gestrichen. Ich sehe keine weiteren Konsequenzen in diesem Test.

(JFish.java:56) ist result = new JavaFish().jrSetMotorEx(ifm.iHandle(serial), number, direction, speed); und iHandleCheck wirft die Exception.

equals() aus Pair:

	@Override
	public boolean equals(Object obj) {
		if(obj != null && this.getClass().equals(obj.getClass())) {
			return this.serial == ((Pair) obj).serial;				
		}
		return false;
	}

Ich glaube dass contains funktioniert. Im Debugger sieht es gut aus.

Es ist schon richtig, dass es gemein für das Modell wäre ihm das Interface zu nehmen wärend es Benutzt wird. Aber wenn die Threads sich darum Kümmern fängt das gerät ja sofort wieder an zu laufen. So könnten sogar alle Geräte auf scheinbar auf einmal Laufen.

Achso, ich glaube es ist nicht Relevant, dass die Methoden in JFish synchronized sind. Das war früher nötig und ich habe noch nicht entschieden, dass sie überflüssig sind. Gibt es einen dringenden Grund dass sie nicht sychronized sein sollten?

 

[SlaterB]

die Schleifen mit den 8 Fischen funktionieren, erst wenn der 9. dazukommt, gibt es ein Problem?
dann könnte der von mir angesprochene Punkt ein Problem sein, der 9. Thread löscht eines der ersten 8,
und gleichzeitig arbeitet einer der ersten 8 damit

logge genau, welcher Thread sich an Position 0 schreibt, wahrscheinlich Nummer 11, den könntest du zur Sicherheit auch 100ms Vorsprung vor den weiteren 7 am Anfang geben,

dann logge, in welchem Thread die Exception auftritt, doch wohl nicht im 9., sondern im ersten Thread?
verwende ein try/catch mit Logausgabe der Threadnummer/ serial

------

du solltest wohl nicht Closen, während ein Fisch in Benutzung ist, da musst du besser synchronisieren, nicht ganz leicht,
und falls du erstmal den Aufwand mit dem getrennten Zugriff hast, könntest du dir das Closen praktisch auch sparen,
dann könnte der 9. Thread auch den Fisch des ersten Threads nehmen, falls der nicht unpassend konfiguriert ist

wait/noty bzw. höhere Java-Locks, Producer/Consumer-Beispiele bekannt, falls du diese Richtung verfolgst?
synchronized ginge auch, nicht unbedingt auf die Handler, sondern wohl separate 8 Objekte


> Gibt es einen dringenden Grund dass sie nicht sychronized sein sollten?

gemeint war wohl, dass du dir im Moment nichts darauf einbilden sollst, dass sie synchronized sind,
solange alle getrennte Objekte verwenden, bringt das gar nichts (falls überhaupt ein Nutzen besteht)

 

[Mappenz]

Die Zuordnung der Interfaces verändert sich bis nicht bis Interface 7 vergeben ist. Ich habe nur die erste Vergabe geloggt.

Das letzte Model wirft die Exception. Das kommt davon, dass iHandleCheck die Exception wirft wenn jrOpenInterface jfError zurück gibt. Das Passiert, weil wenn 29 ankommt und ein Interace haben will Interface 0 nicht richig geschlossen wird. Folglich JavaFish auch kein neues aufmachen kann.

11 erhält Interface 0
13 erhält Interface 1
21 erhält Interface 2
23 erhält Interface 3
3 erhält Interface 4
5 erhält Interface 5
17 erhält Interface 6
27 erhält Interface 7
Exception von 29 Verursacht

Ohne den Check siehts so aus damit kann ich auch nicht mehr anfangen. JavaFish ist ein Wrapper für irgendwas das in C++ geschrieben ist. Den Code habe ich leider nicht.

11 erhält Interface 0
21 erhält Interface 1
13 erhält Interface 2
23 erhält Interface 3
3 erhält Interface 4
5 erhält Interface 5
17 erhält Interface 6
27 erhält Interface 7
29 erhält Interface -536870911
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x18f11c78, pid=836, tid=5132
#
# JRE version: 6.0_26-b03
# Java VM: Java HotSpot(TM) Client VM (20.1-b02 mixed mode windows-x86 )
# Problematic frame:
# C  [umFish40.dll+0x1c78]
...
#

Ich halte es für plausibel dass ein Thread dem anderen in die Quere kommt. Also werde ich mal etwas Zeit ins locken investieren. Die Konzepte des Threadings sind mir nicht bekannt, aber was du erwähnt hast kann ich nachlesen. Mit Synchronized werde ich bei der momentanen Architektur nicht weit kommen.

Ich habe InterfaceManager, speichert wem welches Interface gehört. Hier ist iHandle(serial) drin.
Dann JFish, hat ein HandleManager um Interfaces zu beziehen. bietet die Schnittstelle zur Steuerung der Modelle.
Und die Threads, die könnten wegen mir auch alle ein JFish Objekt haben, vielleicht reicht es schon dieses Objekt zu synchonisieren. Ist das möglich?

 

[SlaterB]

auf ein Objekt, welches erst erstellt werden muss, ist grundsätzlich schlecht zu synchronisieren,
was ist am Anfang wenn es noch null ist und drei Thread gleichzeitig drauf zugreifen und vielleich alle 3 eins erstellen,
weil noch keine Synchronisation möglich ist

---

ist es eigentlich überhaupt möglich eines der Objekte wieder erfolgreich zu closen?,
funktioniert es ohne Threads hintereinander weg, 8 öffnen, eins schließen, eins öffnen usw.?
wenn du aber nur noch öffnen und wiederverwenden bereiben möchtest, dann wäre das nicht so wichtig

 

[Mappenz]

Ich würde es in Kauf nehmen, eine statische JFish instanz zu haben.

Closen geht eigentlich sehr gut, hat sogar bei den Threads ohne while funktioniert. Bevor ich mich daran gemacht die Modelle gleichzeitig laufen zu lassen auch ausgiebig genutzt. Es gibt einen alten Teil und einen Neuen. JFish ist neu und auch alles was der alte Teil kennt. Der alte Teil sagt den Modellen was zu tun ist und es laufen alle 15 Modelle durch und zwar belliebig oft. JFish und was sich dahinter versteckt habe ich geschrieben, dass nichts passiert. Blöd dass das mit den Threads in die Hose geht.

Mein erstes Ziel ist dass ein Thread dauernd alle Sensoren pollt und dann irgendwelche Beobachter benachrichtigt wenn sich was tut. Das ist aber unter Umständen das gleiche Problem, wie dass alle Modelle gleichzeig laufen. Letztes ist viel einfacher nachzuvollziehen.

Ich könnte ein Interface für die Sensoren abzwacken. Aber das ist nicht befriedigend. Erstens ist das nicht schön. Zweitens, kann ich dann zwar wissen wo Arbeit wartet, aber was mach ich dann damit. Aber welches Model schalte ich dafür ab, in welchem Zustand ist es dann? Es wäre schon angebracht, wenn alle Modelle wenigstens so aussehen könnten als würden sie paralell laufen.

 

[Mappenz]

Habe mal versucht selbst Locks zu Implementieren. Das hat leider nicht geklappt.

public synchronized int iHandle(int serial) throws InvalidIHandleException {
		int iHandle = jrError;	
		Pair cpair = new Pair(serial, iHandle);
		if(pairs.contains(cpair)) { //we use iHandle only when we want to use the interface, so we need to take care that its locked, and that pairs is sorted correctly
			Pair pair = pairs.remove(pairs.indexOf(cpair));
			pairs.addLast(pair);
			pair.lock();
			iHandle = pair.iHandle;
		} else if(pairs.size() > 0 && pairs.getFirst().isLocked()) {//if the first is locked all are locked, the pairs are sorted that way
			iHandle = jrLocked;
		} else {
			if(pairs.size() >= SIZE) {  //if we have maximum number of opened, also we already know there are unlocked pairs,
				iHandle = pairs.removeFirst().iHandle;					
				int i = new JavaFish().jrCloseInterface(iHandle); //new instance necessary, because JavaFish instances might expire	
				System.out.println(Integer.toHexString(serial) + " schließt " + iHandle + " Status " + i);
			}
			iHandle =  new JavaFish().jrOpenInterfaceUSB(ftDCB, serial);//new instance necessary, because JavaFish instances might expire
			iHandleCheck(iHandle);
			pairs.addLast(new Pair(serial, iHandle));
			pairs.getLast().lock();
			System.out.println(serial + " erhält " + iHandle);
		}
		return iHandle;
	}
	/**
	 * Unlock the interface of the model with serial number serial
	 * @param serial the serial number of a model
	 */
	protected synchronized void unlock(int serial) {
		Pair cpair = new Pair(serial, jrError);
		if(pairs.contains(cpair)) {
			Pair actualPair = pairs.remove(pairs.indexOf(cpair));
			actualPair.unlock();
			pairs.addFirst(actualPair);
		}
	}

Das wird so Aufgerufen:

	public int setMotorEx(int serial, int number, int direction, int speed) {
		int result = jrError;
		try {
			int iHandle = ifm.iHandle(serial);
			if(iHandle != InterfaceManager.jrLocked) {
				result = new JavaFish().jrSetMotorEx(ifm.iHandle(serial), number, direction, speed);				
			}
			ifm.unlock(serial);
		} catch (InvalidIHandleException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		return result;
	}

Ausgabe:

17 erhält 0
35 erhält 1
23 erhält 2
5 erhält 3
3 erhält 4
33 erhält 5
19 erhält 6
39 erhält 7
29 schließt 7 Status -536870911

Die Interfaces werden nur von der synchronisierten methode iHandle(int) angefasst. Dort werden sie auch jedesmal gesperrt. Wenn sie gesperrt sind werden sie auch nicht gelöscht oder neue geöffnet. Der Caller wird informiert und versucht nicht Motoren zu starten.