[Java] Exklusiver Zugriff auf Tinkerforge

[teichsta]

Hallo Zusammen,

 

wir nutzen die Tinkerforge Module zur Testautomatisierung. Dafür müssen wir beim Ablauf der Tests sicherstellen, dass immer nur ein Test gleichzeitig auf den Tinkerforge Stack zugreift.

 

Aktuell lösen wir das darüber, dass wir einen Port eines Relay-Bricklet so lange einschalten wie der Stack besetzt ist und ihn am Ende wieder ausschalten. Nicht schön (und vor allem auch nicht Ressourcen-schonend), aber es geht.

 

Habt ihr vielleicht noch bessere Ideen?

 

Wir greifen von unterschiedlichen VMs auf den gleichen Stack zu. Das halten einer statischen Variable ist also keine Option. Überhaupt würde wir ungern auf "Clientseite" einen Status einführen, sondern lieber irgendein magischen Register auf dem TF stack setzen :-).

 

Wäre für jeden Hinweis dankbar,

 

Thomas E.-E.

 

[batti]

Hallo Thomas,

 

anstatt wirklich einen mechanischen Schalter zu betätigen könntet ihr einen anderen "setter" nutzen. Musst mal durch die API gehen ob sich da nicht irgendetwas anderes finden lässt.

 

Problematisch könnte aber allgemein dabei sein, dass das nicht wirklich sicher ist. Nachdem du den Status abgerufen hast kann ein anderer ihn schon wieder gesetzt haben.

 

Grüße

[AuronX]

Man kann ja die CallbackPeriod von irgendwas als Semaphore nutzen

 

Aber wie schon von Batti gesagt: Das ist nicht sonderlich Thread-safe.

 

Wie wäre es wenn ihr euren eigenen Brickd schreibt (bzw. den originalen modifiziert).

 

Einfache Variante: Nur eine offene Verbindung, danach keine weitere akzeptieren.

 

Fortgeschritten: der Brickd reagiert auf einer virtuellen UID auf einen Test-And-Set Funktionsruf (dadurch sind echte Semaphoren/Mutexe möglich).

[teichsta]

Hi,

 

Wie wäre es wenn ihr euren eigenen Brickd schreibt (bzw. den originalen modifiziert)

 

das klingt gut, jedoch nutzen wir nicht den brickd sondern erreichen den TF stack über die WiFi Extension. Das würde bedeuten: Firmware schreiben, oder?! Damit wären wir dann aber ganz schön Lowlevel unterwegs ... jedenfalls mehr, als mir das eigentlich lieb wäre ;-).

 

Gruß,

 

Thomas E.-E.

 

[AuronX]

Hmmm... könnte im Rahmen der Unit-Tests egal sein, dass es WiFi ist... (außer organisatorisch).

 

Von eigener Firmware zu diesem Zweck würde ich abraten, das wäre overkill.

 

Ideal wäre es für Unit-Tests eigentlich, wenn jedes Device ein zugehöriges Interface hätte. Dann könnte man die Devices ganz einfach mocken und ihr wärt nicht auf echte Hardware angewiesen. (Wie wollt ihr testen, ob Methode x mit einer TimeoutException klarkommt?)

[teichsta]

Hmmm... könnte im Rahmen der Unit-Tests egal sein, dass es WiFi ist... (außer organisatorisch).

 

hmm, verstehe ich noch nicht so ganz. Im WiFi-Fall nutzen wir doch gar keinen "externen" brickd, können also auch einen Einfluss auf das Connection-Handling nehmen, oder?

 

Ideal wäre es für Unit-Tests eigentlich, wenn jedes Device ein zugehöriges Interface hätte. Dann könnte man die Devices ganz einfach mocken und ihr wärt nicht auf echte Hardware angewiesen. (Wie wollt ihr testen, ob Methode x mit einer TimeoutException klarkommt?)

 

da gebe ich Dir recht ... wäre nett :-)

 

Im Moment lösen wir das organisatorisch. Und zwar so, dass die Tests, denen sicher ein TF stack zur Verfügung steht eine entsprechende Annotation erhalten.

[AuronX]

Will sagen man könnte den Stack per USB anschließen und hoffen, dass es sich per WLAN gleich verhalten würde.

Was ihr damit natürlich nicht aufdeckt sind Fehler im TF-Protokoll, aber das ist auch nciht die Aufgabe von Unit-Tests.

[teichsta]

Ich glaube meine Erklärung zum Einsatz von TF war bisher noch sehr lückenhaft und wir sprechen daher aneinander vorbei.

 

Wir wollen mit den Unit-Tests nicht den TF Stack testen, sonder TF als einen Testtreiber benutzen, um manuelle Interaktion mit externer Hardware zu simulieren und diese im Rahmen von Integrationstests bereitzustellen.

 

Weil wir im Rahmen der Unit-Tests auf die gleiche Hardware von unterschiedlichen VMs zugreifen, brauchen wir eben den exklusiven Zugriff auf den TF stack.

[borg]

Am einfachsten ist es wahrscheinlich wenn ihr eine weitere VM aufsetzt die einen Mutex implementiert (einfach über Sockets oder so).

 

Das über einen Setter/Getter bei uns im System zu machen ist definitiv nicht sicher. Es könnte ja folgende Abrufreihenfolge passieren

 

VM A: Get -> Ergebnis: Unlocked

VM B: Get -> Ergebnis: Unlocked

VM A: Set -> Lock

VM B: Set -> Lock (kein Fehler)

 

Um schon greifen beide VMs gleichzeitig drauf zu.

 

D.h. ihr braucht eine TryLock Funktionalität, die einen Fehler zurückgibt wenn das Lock schon gesetzt ist.

 

Es ist möglich das auf dem Master Brick zu implementieren, es gibt aber aktuell keinen Setter oder Getter bei uns im System der sowas leisten könnte.