[so] I/O

[Bercea Gabriel]

Just for the tip on the iceberg. Trebuie sa te gandesti, la nivel de 
implementare, cum sunt implementate, si de ce,  sync si async I/O si de 
ce exista astea 2 solutii.

Internally async I/O de multe ori e baza sistemului de operare si metoda 
mai mereu aleasa pentru I/O deoarece permite o mare interactivitate cu 
userul. De obicei async I/O este folosit foarte des in cazuri  de low 
virtual memory, atunci cand sistemul de operare decide ca trebuie sa 
flushuiasca pagini pe disc. Ideea e ca OS ul nu are decat un numar fixat 
de la boot de system worker threads pentru ModifiedPageWriter (MPW).  
Daca fiecare pagina ar fi flushuita sincron atunci utilizatorul ar avea 
de asteptat perioade insuportabil de lungi pentru operatii de genul asta.

Aici nu vorbesc de multiplexare si doar de faptul ca requestul de flush 
pleaca dintr-un anumit system worker thread context si poate se termine 
si in contextul kernel mode al notepadului. Asincron nu inseamna 
neeaparat ca vrei sa sti cum s-a terminat operatia pe care ai 
forwardat-o, care e statusul final, ci inseamna ca nu vreai sa stai dupa 
fiecare operatie sa se termine, ca sa treci la urmatoarea operatie. It 
make a lot of sense on multicore right ? de ce sa nu flushuiesc 2 pagini 
de VM in paralel ?

Same goes for socket, sau orice interactioneaza cu kernel executive ul.

Acum de ce as vrea sync I/O,  internally (f important internally) ?

Pai in primul rand ca sa nu pierd contextul in care se termina operatia. 
Operatiile KM care incep in contextul unui process, si primesc ca input 
o adresa care poate fi tradusa cu PTE ul acelui proces, nu as dori sa o 
procesez in alt context, pentru ca, dupa cum va imaginati, acel proces 
are alt PTE, deci virtual to phisical translationul cade, deci memoria 
accesata vine valida, dar la un moment dat ajunge invalida. Operatiile 
de genul asta de asemenea pot fi terminate in arbitrary thread context, 
though,  insa trebuie sa te folosesti de anumite mecanisme pe care le 
dispune sistemul de operare, gen sa faci memoria rezidenta in ram, si  
sa o poti descrie independent de context si altceva destul de important 
sometimes, dar nu de multe ori vizivil: PTE ul sa nu ajunga sa fie paged 
it's self, dar most of the time poate sa fie. So now you can work 
synchronously and context thread independent.


Example: CreateFile este vine intotdeauna in contextul threadului care 
l-a initiat user mode, si obiectul creat este dependent de context. 
Operatia totusi, post-creatul, poate sa se termine si in alt context 
thread, async adica, insa threadul initial, va face un mic hang, vazand 
operatia ca fiind pending.

Nu se poate spune acelasi lucru pentru un ReadFile sau WriteFile. Ele 
fiind mai mereu async.


Alexandru Goia wrote:
> Buna ziua,
>
> In ce situatii e recomandat sa fac blocking I/O (read, write) si in ce 
> situatii e mai bine sa fac non-blocking I/O ? (Nu ma refer la 
> multiplexed I/O.) Va rog, daca se poate, cu exemple concrete.
>
> Va multumesc.
> Alexandru
> _______________________________________________
> so mailing list
> so at cursuri.cs.pub.ro
> http://cursuri.cs.pub.ro/cgi-bin/mailman/listinfo/so
>
>   

-------------- 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/20080731/cea1045e/attachment.vcf