USB / HID in einem Thread - TJvHidDeviceController.OnDeviceData kommt nicht an

[grl]

Schönen guten Abend!

In einem mittlerweile sehr komplexen und umfangreichen Projekt (D7/WinXP) hab ich einen Thread, der unter anderem für die Abwicklung einer Kommunikation mit einem Gerät über HID zuständig ist.
Dafür wird in dem Thread eine Instanz von TJvHidDeviceController (von Robert Marquardt) angelegt. Der Thread kümmert sich auch um die gesamte Ereignisbehandlung.

Das funktioniert so weit auch sehr gut - wenn denn die entsprechenden Ereignisse auch ausgelöst werden.

Das Problem ist, daß bei sehr hoher Last im Main-Thread das Ereignis "OnDeviceData" des HIDDeviceController nicht mehr ausgelöst wird, bzw. extrem verzögert ausgelöst wird. Das führt aber im USB-Gerät zu einem Überlauf des Sendepuffers und damit zu einem Verlust von Daten.

Mein Verdacht ist folgender:
TJvHidDeviceController verwendet zum Auslesen der Daten einen eigenen Thread, den TJvHidDeviceReadThread. In seinem Execute verwendet der ein Synchronize. Das aber wartet auf den Main-Thread und könnte daher Ursache der nicht mehr auftretenden OnDeviceData-Events sein.

Weiß jemand, warum hier ein Synchronize verwendet wird? Nur damit in der Ereignisbehandlung kein "Blödsinn" passieren kann?

Für jeden Tip dankbar,

Luggi

[himitsu]

Robert kann man ja leider nicht mehr fragen :cry:

Und ich hab jetzt nicht im Kopf was wo passierte,


aber wie wäre es mit einer anderen Idee...
Was lastet denn deinen Hauptthread so aus und kann man das nicht auch in einen Thread auslagern? :angle2:



[add]
Tja, der TJvHidDeviceController ist halt darauf ausgelegt, daß er im Hauptthread läuft, da er teilweise mit Messages arbeitet.

Im Anhang mit einigen kleinen Änderungen:
- wird TJvHidDeviceController, bzw. TJvHidDeviceReadThread in einem Thread erstellt, dann wird ohne Synchronize gearbeitet.


Basis: JvHidControllerClass.pas aus JVCL 3.40

[grl]

Zitat:

Zitat von himitsu (Beitrag 1120805)

Robert kann man ja leider nicht mehr fragen :cry:

Leider - seine freundliche und hilfsbereite Art war schon was besonderes.

Zitat:

Zitat von himitsu (Beitrag 1120805)

aber wie wäre es mit einer anderen Idee...
Was lastet denn deinen Hauptthread so aus und kann man das nicht auch in einen Thread auslagern? :angle2:

Prinzipiell nicht falsch, der Gedanke. Aber das Ding ist schon ziemlich komplex und alle zeitkritischen Sachen sind in eigenen Threads (so 8 oder 9 mittlerweile). Das was da jetzt noch im Hauptthread passiert ist in erster Linie UI-Geschichte - und die in einen Thread legen ist nicht so sinnvoll.

Das Problem tritt ja auch nur manchmal auf - vor allem wenn auf dem Rechner viel los ist. Nachdem aber mit dem System Messdaten aufgezeichnet werden, sollte es einfach NIE passieren - und genau dafür ist das ganze ja auch in einem Thread. Das Konzept mit dem Thread für die USB-Kommunikation wird nur von dem Synchronize im DeviceController durchbrochen - da bringt dann das ganze Multithreading nix...

Zitat:

Zitat von himitsu (Beitrag 1120805)

[add]
Tja, der TJvHidDeviceController ist halt darauf ausgelegt, daß er im Hauptthread läuft, da er teilweise mit Messages arbeitet.

Im Anhang mit einigen kleinen Änderungen:
- wird TJvHidDeviceController, bzw. TJvHidDeviceReadThread in einem Thread erstellt, dann wird ohne Synchronize gearbeitet.

Danke, das hab ich mir auch schon geschnitzt. Ich war mir nur nicht wirklich sicher, ob das Synchronize noch einen anderen Zweck hat, als das Eventhandling sicher zu machen. (Was bei mir egal ist, da meine Event-Routinen alle Thread-safe sind).

Danke für die Mühe,

Luggi

[himitsu]

Da diese Komponente ja standardmäßig (billig) auf eine Form geklatscht wird
und die Events dort angehangen sind, ging er eben davon aus, daß diese Events (standardmäig) nicht threadsicher sind.