Hallo, ich will in einem Thread mit writefile und readfile Daten an 64 unterschiedliche USB Teilnehmer senden. Wenn ich das ganze mit einem Teilnehmer mache und mit Timeout (WaitforsingleObject) und Overlaped arbeite geht alles. Nun will ich aber an alle 64 Daten senden ohne bei jedem Senden zu warten. Beim empfang will ich auch nicht bei jedem warten. Irgendwie würde ich gerne alle 64 Teilnehmer abfrage/was senden und dann reagieren wenn was Empfangen/gesendet wurde. Gibt es dafür eine Möglichkeit? Ich hatte auch schon daran gedacht 64 Threads zu machen aber das mit allen Funktionen daherum zum laufen zu bringen ist fast unmöglich. VG, Peter
Dafür musst du WriteFile und ReadFile ebenfalls overlapped verwenden, und dann WaitForMultipleObjects.
Overlapped ist drin! Das bedeutet auch das ich 64 events brauche oder? Das ist aber auch nicht wirklich einfach zu handhaben.
Peter schrieb: > Das bedeutet auch das ich 64 events brauche oder? Ja, ein HANDLE pro "Write". Naja machste halt ein Array mit OVERLAPPED-Struct's das passt schon.
Wenn ich das aber richtig verstehe mache ich zB. ein Write an alle und muss dann warten bis alle durch sind. Beim Lesen sendet aber nicht jeder Teilnehmer immer Daten. Wenn ich da warte Wie würde man in diesem Fall am besten so was schreiben.
Peter schrieb: > Wenn ich das aber richtig verstehe mache ich zB. ein Write an alle und > muss dann warten bis alle durch sind. Ja, oder nur an einige; musst halt nur die, die tatsächlich geschrieben wurden, an WaitForMultipleObjects übergeben. > Beim Lesen sendet aber nicht jeder Teilnehmer immer Daten. > Wenn ich da warte WaitForMultipleObjects kehrt zurück wenn mindestens einer was gelesen hat. Du benutzt dann WaitForSingleObject mit Timeout 0 (ist ja dann nichtblockierend) um herauszufinden bei wem tatsächlich was reingekommen ist. > Wie würde man in diesem Fall am besten so was schreiben. Musst du mal Doku lesen und selber überlegen.
eventuell ist es sinnvoller gleich 64Threads zu starten. Dann kannst du blockierend zu jeden Teilnehmer senden. Dafür müsste mal aber mehr über die Aufgabenstellung wissen.
Peter II schrieb: > eventuell ist es sinnvoller gleich 64Threads zu starten. Peter schrieb: > Ich hatte auch schon daran gedacht 64 Threads zu machen aber das mit > allen Funktionen daherum zum laufen zu bringen ist fast unmöglich. Threads haben immer das Problem dass man sie kompliziert synchronisieren muss, vor allem bei so einer Anzahl.
Dr. Sommer schrieb: > Threads haben immer das Problem dass man sie kompliziert synchronisieren > muss, vor allem bei so einer Anzahl. aber den Vorteil das es wirklich gleichzeitig passiert. Heute hat fast jede CPU 4 oder mehr kerne. Warum sollte man die Resourcen nicht nutzen? Und die Synchronisieren finde ich einfacher als OverlappenIO.
Peter II schrieb: > aber den Vorteil das es wirklich gleichzeitig passiert.Heute hat fast > jede CPU 4 oder mehr kerne. Warum sollte man die Resourcen nicht nutzen? Das hat keinerlei Einfluss. Das lesen/schreiben wird vom Kernel gemanagt, und das ist unabhängig davon wie viele Threads das Programm verwendet. Außerdem wird während des I/O die CPU onehin kaum beansprucht... Ob nun 64 Threads warten oder nur einer macht keinen Unterschied. > Und die Synchronisieren finde ich einfacher als OverlappenIO. Dann bist du entweder ein Genie oder hast noch kein richtiges Multithreading gemacht :-)
Danke für die Antworten. Ich habe mir nochmal die ganzen Read/Write Funktionen angesehen und diese abgesichert. War doch möglich! Nun Starte ich bis zu 64 Threads und lasse die alle vor sich hin werkeln. Mit 10 USB Teilnehmern habe ich es jetzt schon getestet und angeblich liefern die alle Daten. Muss nur noch raus finden wie Parallel die wirklich Arbeiten. Also wie lange ein Thread durchgängig Arbeitet und dann auf den Anderen Schaltet und zum nächsten ...... Hat hierfür jemand einen Tip? Ich werde, wenn ich Zeit habe, versuchen das ganze doch auf WaitForMultipleObjects um zubauen. Das erscheint mir auf Dauer der bessere Weg auch wenn der jetzige auch geht.
Eine Woche und etliche Stunden Arbeit später. Alles ist umgebaut und es geht. Es funktioniert sogar besser als die Version mit den 64 Threads. Habe es es nun mit allen 64 USB Teilnehmern getestet und mir die Verarbeitungsreihenfolge angesehen. Die neue Variante ist deutlich besser. Die Tasks haben sich sozusagen immer blockiert, es läuft halt immer nur einer für eine gewisse Zeit und die anderen müssen warten. Nun arbeitet nur einer und sendet & liest halt von allen gleichzeitig. Danke nochmal für die Hilfe (Dr. Sommer). Peter
Peter schrieb: > Die Tasks haben sich sozusagen immer blockiert, es läuft halt > immer nur einer für eine gewisse Zeit und die anderen müssen warten. warum war das so? Hattest du selber für die Locks gesorgt (CriticalSection/Mutex) oder war es wirklich das write was blockiert hatte? Wie viele CPUs hatte das System? Ich hätte erwartet das einige Threads wirklich gleichzeitig arbeiten, aber hier könnte wirklich USB zu einem Problem werden.
Ich hatte das ganze verhalten an meinen Debug Ausgaben gemerkt. Da kamen halt immer nur Task 1W(rite)WWWWWWR(read)RRRR T2 WWWWWWWWRRRRR ..... Nun kommt W1W2W3W4... R1R2R3.... Ob die Locks von den ganzen Absicherungen kommen kann ich nicht sagen, es wäre aber genug Zeit gewesen in der Zwischen Zeit mal einen Anderen Task laufen zu lassen. Habe nur eine CPU auf dem Testsystem P4. Wo nun genau das Problem ist werde ich jetzt nicht mehr testen. 64 Reads direkt hintereinander und dann ein Wait ALL (2ms) funktioniert auf jeden Fall gut.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.