[so] Performance Notice - pentru implementari viitoare de asynch I/O pe windwos

Bercea Gabriel gamitech at gmail.com
Thu Jun 12 02:08:36 EEST 2008


Scriu postul asta pentru ca mi se pare ca tema asta e printre cele mai 
interesante, si a carei utlitate, e mult mai transparenta decat la 
celelate teme.

Pentru cine a folosit metoda completion ports.

Performance tips:
De ce numarul de threaduri din pool este bine sa fie in unele cazuri mai 
mare decat numarul de procesoare existente, si cum functioneaza de fapt 
completion porturile.

Pentru sistem dual core, de ex.
Un completion port face schedduling LIFO pentru threadurile care in wait 
state, pentru o notificare I/O . Daca unul din threaduri este deblocat, 
atunci el trece din coada
interna de waiting a completion portului, in coada running. Completion 
portul in acest moment, stie ca acel thread este in executie. Cat timp 
threadul este in executie, portul
primeste inca o notificare I/O si trezeste alt 2 lea thread. In acest 
caz.cele 2 threaduri servesc notificari. Problema este urmatoare. Daca 
in timpul servirii unui request unul din
threaduri face apel la o un functie de wait, atunci timpul de procesor, 
trece de pomana. In acest moment coada de waiting de la completion port 
creste cu 1, chiar daca  threadul nu este
in waiting cu GetQuedCompletionStatus. Asta inseamna ca daca ar fi un al 
3 lea thread asteptand requesturi pe completion port, acesta ar fi 
lansat. Asta se si intampla de fapt,
si performanta creste. Se recomanda ca poolul de threaduri sa fie mai 
mare decat numarul de procesoare (si mai exact 2*no_CPUs) atunci cand se 
face procesare intensiva pe fiecare request.
Aceste este un rezultat heuristic, care a fost scos in urma multor 
testari a acestui concept.

O alta chestie care ar putea da boost, executiei, si care o gasesc utila 
in unele cazuri, in care chiar nu te intereseaza cum s-a terminat un I/O 
request si nu il vrei procesat.
Pentru urm scenariu, am in completion port, un hFile, asupra caruia am 
facut un write, al carui deznodamant nu ma intereseaza, nu vreau sa il 
procesez, nu vreau ca
GetQueuedCompletionStatus sa imi returneze pentru el. Here is the 
undocummented trick :P

Overlapped.hEvent = CreateEvent(NULL, TRUE, FALSE, NULL);
Overlapped.hEvent = (HANDLE) ((DWORD_PTR) Overlapped.hEvent | 1);
WriteFile(..., &Overlapped);

Acest caz, in care overlappedul are eventul OR-uit pe biti cu 1, nu va fi pus in coada de I/O a completion portului, si deci GetQuedCompletionStatus
 nu se va fi notificat pentru el.

Nu uitati 
CloseHandle((HANDLE) ((DWORD_PTR) Overlapped.hEvent & ~1));
Negati 1 OR-uit pentru CloseEvent, logic.

CompletionPort urile sunt mecanisme destul de complexe si putin documentate, si sper sa fi fost de folos ce am spus. Asta daca se face aim pe performanta.

Bafta.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: gamitech.vcf
Type: text/x-vcard
Size: 222 bytes
Desc: not available
Url : http://cursuri.cs.pub.ro/pipermail/so/attachments/20080612/f9f9f80e/attachment.vcf 


More information about the so mailing list