wie bei Writefile vorgehen ohne Timeout

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.