FTDI DLL thread sicher in C#

[kollo (Gast)]

Hallo,

ich beschäftige mich neu mit Multithread Programmierung. Folgendes hab 
ich vor:

n FTDI Kabel. Ich will für jede Kabel einen eigenen Thread starten, der 
mit dem FTDI kommuniziert, die Daten vorverarbeitet und dann in eine 
eigenen Datei schreibt.

Da ich ja jetzt gemeinsam von n Threads auf die FTDI DLL zugreife, frage 
ich mich, ob ich da Probleme zu erwarten hab.

[Fabian O. (xfr)]

Das müsstest Du streng genommen in der Dokumentation der FTDI-DLL 
nachschauen, denn das hängt von der Implementierung der Funktionen darin 
ab.

Wenn es pro Device nur einen Thread gibt, können eigentlich keine 
Konflikte entstehen. Du hast ja zu jedem Device ein eigenes Handle. Das 
ist normalerweise ein Zeiger auf eine devicespezifische Instanz einer 
Datenstruktur oder sogar identisch zum Windows-File-Handle des Devices. 
Damit sind die Devices komplett unabhängig voneinander, sofern die DLL 
nicht noch unsynchronisiert auf andere "globale" Resourcen zugreift.

Selbst bei mehreren Threads pro Device würde ich auf Ebene einzelner 
Funktionsaufrufe keine Probleme erwarten, da Windows die 
File-Operationen pro Handle schon intern synchronisiert. Außerdem sorgt 
ein ordentlich implementierter Gerätetreiber ebenfalls dafür, dass 
Befehle, die nicht parallel möglich sind, synchronisiert werden, sogar 
prozessübergreifend.

Wenn Du allerdings z.B. ein Kommando per Write an das Device sendest und 
dann per Read die Antwort auf das Kommando liest, musst Du selber dafür 
sorgen, dass zwischen dem Write und dem Read kein anderer Thread auf das 
gleiche Device zugreift. Das kann bei Dir aber ja nicht passieren, wenn 
Du pro Device ohnehin nur einen Thread hast.

[kollo (Gast)]

Danke, Fabian.

[c.m. (Gast)]

Fabian O. schrieb:
> Wenn es pro Device nur einen Thread gibt, können eigentlich keine
> Konflikte entstehen.

eigentlich :)
ich hatte mit java grad ein nettes problem das genau in die scharte 
haut: mehrere FOP (apache framework für XSL-FO tansformationen) threads 
werden gestartet, und ich bekomme direkt ein paar 
ConcurrentModificationExceptions.
die ersten paar threads (so 3 von 24) sterben, die anderen laufen ohne 
probleme weiter.
das problem war, das die FOP-threads beim starten 
java.awt.color.ICC_ColorSpace (wird zur erzeugung von PDF's gebraucht) 
initialisiert, das nicht threadsicher ist.

lösung war btw, dass ich ICC_ColorSpace selbst initialisiere bevor ich 
FOP starte.

fazit: versuch macht kluch. man kann schlecht voraussagen was alles 
passieren kann, wenn die daten durch x objektschichten rutschen.