Jump to content

Synchronisierung "sendRequestExpectResponse()"


Recommended Posts

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.

Link to comment
Share on other sites

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 ^^

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...