od jakiegos czasu borykam sie z pewnym problemem.
program ma tylko 1 watek.
<ort>wykozystuje </ort>rozproszone io (czyta z wielu plikow, zapisuje do 1 / czyta z 1 pliku, zapisuje do wielu / czyta z wielu i pisze do wielu).
Wszsytko w oparciu o funkcje MsgWaitForMultipleEventsEx().
Jest kilka zasad wg ktorej ma on dzialac, miedzy innymi pelna i uczciwa konkurancja modulow.
tzn jedynym wyznacznikiem wydajnosci transferu jest szybkosc samej operacji io (np zapis na dysk), a nie pozycja w kolejce/poprzedni modol/typ pliku.
I tu jest pies pogrzebany.
Mam do wyboru:
ReadFileEx - calosc moge zreallizowac w APC (inaczej nie mialo by sensu), ALE w momencie wywolania zagniezdzonego ReadFileEx czy innej funkcji ktora kolejkuje mi APC zaczynam sie scigac. Zakonczenie apc i powrot w stan alterable wait (WaitForMultiple*) vs zakonczenie IO i zakolejkowanie kolejnego APC, ktore wykona sie zaraz po tym jak zwroce obecne. Zazwyczaj APC wygrywa, i mam deadlocka - watem wisi na 1 ciagu apc az przesle cale dane. Pozniej zazwyczaj mam to samo przy wysylaniu. Itak w kolko ort!, identycznie jak byl uzyl synchronicznego ReadFile.
ReadFile + Event: z tej metody <ort>korzystam</ort>, mimo to ze mam limit 63 handli.
Ale tutal zgodnie z dokumentacja, ReadFile moze zakonczyc synchronicznie nawet jak ma handle z flaga overlapped. I w 99% przypadkow tak sie wlasnie dzieje. Nie dosc ze ReadFile blokuje mi program ciut dluzej niz powinien, to mnie zostawia z wyborem:
- przetwarzac dalej i ryzykowac ze ciagle bedzie blokowac (return TRUE).
- mimo to ze operacja sie zakonczyla, przekazac event to WaitForMultiple zeby tylko nie blokowac innych.
Szkoda ze flaga FILE_FLAG_OVERLAPPED nie wymusza asynchronicznego io, czyli ZAWSZE readfile/writefile zwroci io_pending, i nie bedzie mi blokowal watku.
czy to co napisalem jest zgodne z rzeczywistoscia? jesli tak, to jak wymusic uczciwe rozdzielenia zasobow miedzy wiele konkurentnych operacji i/o?