Synchronisierung "sendRequestExpectResponse()"

[remotecontrol]

Hallo zusammen,

 

im der Methode Device.sendRequestExpectResponse wird die ganze Zeit der Socket-Mutex der IPConnection gehalten, in der Art (Java Beispiel):

 

synchronized(requestMutex) { synchronized(ipcon.socketMutex) {

 

Ist das notwendig?

Das bewirkt, dass bis die Response zurück ist keinerlei andere Commands gesendet werden können, auch keine, die keine Response erwarten.

 

In API Version 1 wurde nur der IPConnection.write synchronisiert. Damit war es möglich, dass ein anderes Device schon früher wieder ein Command senden konnte.

 

Verarbeitet der Master-Brick eh alles seriell oder könnte man theoretisch weitere Commands senden? Dann würde es sich lohnen, sich die Synchronisierung genau anzusehen.

[AuronX]

Hierzu auch als Referenz:

https://github.com/Tinkerforge/generators/pull/32

 

Regarding the requestLock inside sendRequestNoResponse(): It could probably be removed' date=' but you don't gain much form that expect making it easier to overflow the communication buffers with too many setter calls in flight.[/quote']

 

Deine Frage wie der Master die Calls verarbeitet finde ich sehr interessant! Soweit ich das verstanden habe sind alle Komponenten unabhängig genug voneinander, dass ein Setter (oder ein Getter eines anderen Device) zwischendurch problemlos aufgerufen werden können müsste. Eine offizielle Antwort ist aber mehr Wert als meine ^^

[remotecontrol]

Ich habe bei mir die Device.sendRequestExpectResponse und sendRequestNoResponse mal so umgebaut:

 

synchronized(requestMutex) { 
if (ipcon.getConnectionState() != IPConnection.CONNECTION_STATE_CONNECTED) {
	throw new NotConnectedException();
}
...

 

Also den 2. synchronized Block entfernt und IPConnection.write sieht dann so aus:

 

void write(byte[] data) {
try {
    synchronized(socketMutex) {
        out.write(data);
    }
} catch(java.io.IOException e) {
	e.printStackTrace();
}
}

 

Damit läuft meine Steuerung deutlich flüssiger, weil Statusabfragen, wie Ambilight-Sensor oder Spannung/Strom auslesen andere Requests ohne Response nicht mehr vollständig blockieren. Ob das so "gut" ist oder eher Probleme im Master bereiten kann (wegen Parallelität) kann ich so nicht sagen.

[photron]

In API Version 1 wurde nur der IPConnection.write synchronisiert. Damit war es möglich, dass ein anderes Device schon früher wieder ein Command senden konnte.

 

Ah ich sehe was du meinst. Du beziehst dich auf den socketMutex. Der ist neu in v2 und führt dazu dass alle Setter/Getter Aufrufe aller Devices der selben IPConnection serialisiert werden. Das ist schlecht für die Performance mit mehreren Threads. Da haben wir nicht aufgepasst

 

AuronX, du beziehst dich auf den requestMutex im Setter Fall. Wie im Pull Request schon gesagt sehe ich da keine Problem das zu ändern. In remotecontrols Fall über WLAN (nehme ich an) wo die Getter Roundtriptime höher ist ist der Gewinn einer solchen Änderung natürlich deutlich größer als über USB.

 

Damit steht jetzt feineres Locking auf der TODO Liste für die nächste Release.

[AuronX]

Stimmt, mein Fall war nur relevant wenn das gleiche Device in mehreren Threads genutzt wurde.

Bei Java ist es ja auch bei mehr als einem Device ein Problem. Hoffe der Beitrag war trotzdem halbwegs relevant

 

Viele Grüße

Jan

[photron]

Das Locking ist mit der letzten Version in allen Binsings verbessert worden.

 

In allen Bindings wird das Request Lock nur noch für Getter Aufrufe (und Setter mit Response Expected Flag) gehalten. Das Socket Lock wird nur noch direkt um die Interaktion mit dem Socket gehalten. Es wird in Java nicht mehr für die gesamte Zeit eines Getter Aufrufs gehalten.

[remotecontrol]

Schaut gut aus - meine Anwendung läuft damit flüssig und ich nutze wieder die Standard API.

 

Vielen Dank