Jump to content

SUBIECTE NOI
« 1 / 5 »
RSS
Incalzire casa fara gaz/lemne

Incalzire in pardoseala etapizata

Suprataxa card energie?!

Cum era nivelul de trai cam din a...
 probleme cu ochelarii

Impozite pe proprietati de anul v...

teava rezistenta panou apa calda

Acces in Curte din Drum National
 Sub mobila de bucatarie si sub fr...

Rezultat RMN

Numar circuite IPAT si prindere t...

Pareri brgimportchina.ro - teapa ...
 Lucruri inaintea vremurilor lor

Discuții despre TVR Sport HD.

Cost abonament clinica privata

Tremura toata, dar nu de la ro...
 

Synchronous vs Asynchronous I/O

- - - - -
  • Please log in to reply
13 replies to this topic

#1
Sess

Sess

    Junior Member

  • Grup: Members
  • Posts: 68
  • Înscris: 20.01.2016
Salut,

Citeam acest articol: https://msdn.microso...3(v=vs.85).aspx despre sync vs async I/O.

In asynchronous I/O spune ca un thread primeste un request I/O si acesta este trimis kernelului spre procesare, iar in acest timp, preia alt job.

Intrebarea mea este: urmatorul job pe care il preia, nu trebuie trimis tot kernelului spre procesare, si atunci nu trebuie sa astepte finalizarea primului job, deci tot un fel de "wait state" ca in cazul synchronous I/O?

#2
neagu_laurentiu

neagu_laurentiu

    Guru Member

  • Grup: Senior Members
  • Posts: 40,570
  • Înscris: 30.07.2003
CPU executa mai multe task-uri in paralel (real sau nu) asa ca nu-s serializate toate actiunile.

Edited by neagu_laurentiu, 06 November 2017 - 07:25.


#3
_Smiley_

_Smiley_

    Guru Member

  • Grup: Senior Members
  • Posts: 19,980
  • Înscris: 24.02.2006

 Sess, on 06 noiembrie 2017 - 07:16, said:

Salut,

Citeam acest articol: https://msdn.microso...3(v=vs.85).aspx despre sync vs async I/O.

In asynchronous I/O spune ca un thread primeste un request I/O si acesta este trimis kernelului spre procesare, iar in acest timp, preia alt job.

Intrebarea mea este: urmatorul job pe care il preia, nu trebuie trimis tot kernelului spre procesare, si atunci nu trebuie sa astepte finalizarea primului job, deci tot un fel de "wait state" ca in cazul synchronous I/O?
"job" este o denumire generica, nu se refera doar la I/O. de exemplu, un job poate fi si urmarirea tastaturii si reactia la apasarea unei taste. este genul de job care poate fi executat foarte bine in paralel cu salvarea unui fisier, de exemplu.

#4
fqx

fqx

    Senior Member

  • Grup: Senior Members
  • Posts: 6,181
  • Înscris: 23.08.2014

 Sess, on 06 noiembrie 2017 - 07:16, said:

Salut,

Citeam acest articol: https://msdn.microso...3(v=vs.85).aspx despre sync vs async I/O.

In asynchronous I/O spune ca un thread primeste un request I/O si acesta este trimis kernelului spre procesare, iar in acest timp, preia alt job.

Intrebarea mea este: urmatorul job pe care il preia, nu trebuie trimis tot kernelului spre procesare, si atunci nu trebuie sa astepte finalizarea primului job, deci tot un fel de "wait state" ca in cazul synchronous I/O?
E vorba de thread, el trimite request, si in functie de modul I/O asteapta sau nu finalizarea requestului. Procesorul lucreaza oricum cu zeci chiar sute de threaduri odata.Trebuie sa vezi procesorul ca avand mai multe functii pe un core, iar in functie de asta sint alocate requesturile.Un thread poate face un request de calcul matematic, iar apoi sa treaca mai departe la o operatie de citire din memorie, fara sa astepte finalizarea calculului.

#5
karax

karax

    Guru Member

  • Grup: Senior Members
  • Posts: 21,839
  • Înscris: 14.10.2017
Si mai exact blocarile se petrec cand instructiunile sunt mai multe decat numarul tranzistoarelor asa ca unele instructiuni "stau pe bara" si asteapta sa intre in teren. Insa eu m-am intrebat intotdeauna cum naibii poti sa ai blocaje la calculator din moment ce viteza curentului este cea a vitezei luminii?

#6
_Smiley_

_Smiley_

    Guru Member

  • Grup: Senior Members
  • Posts: 19,980
  • Înscris: 24.02.2006
ai nevoie de o gramada de tranzistoare pentru a executa o singura instructiune :)
si componentele electronice nu-si schimba starea instantaneu, d'asta pc-ul nu "merge" chiar cu viteza luminii.

#7
Sonic3R

Sonic3R

    Member

  • Grup: Members
  • Posts: 836
  • Înscris: 02.02.2011

 karax, on 06 noiembrie 2017 - 08:40, said:

Insa eu m-am intrebat intotdeauna cum naibii poti sa ai blocaje la calculator din moment ce viteza curentului este cea a vitezei luminii?
Blocajele se intampla din diverse motive. Poate niste cicluri do-while necorespunzatoare, niste instructiuni care pot dura mai mult ... astfel se umple stiva care rezulta niste exceptii/erori

#8
cspot

cspot

    Guru Member

  • Grup: Senior Members
  • Posts: 12,855
  • Înscris: 22.07.2004
Procesorul executa un numar de threaduri simultan. Mai exact doar un singur thread este executat la un moment dat pentru o perioada limitata de timp.
     In cazul unui program care vrea sa citeasca ceva de pe HDD cererea este trimisa catre HDD si apoi se asteapta raspunsul. Hdd-ul nu va raspunde imediat. Cautarea si citirea datelor de care ai nevoie necesita timp. Citirea se face rapid, dar in timpul asta procesorul sta de pomana.
     Ca atare, programul tau va consuma timp de procesor de pomana. In cazul citirii asyncrone se face cererea catre HDD iar colectarea datolor citite se face ulterior cand acestea sunt disponibile. In timpul asta programul poate sa execute altceva sau poate sa nu execute nimic. Procesorul va avea timp sa execute alte threaduri.


#9
modoran

modoran

    Senior Member

  • Grup: Senior Members
  • Posts: 8,310
  • Înscris: 08.02.2011
Mie niciodata nu mi-au placvut API-urile cu fisiere in mod asincron. Daca ai nevoie de asa ceva iti creezi propriul thread si folosesti tot API-urile sincrone.

Astea asincrone practic intrerup threadul existent si executa o rutina ( in contextul aceluiasi thread ) atunci cand termina de citit/scris fara sa astepte, dar o fac haotic si e destul de greu de lucrat cu ele.

#10
tatarduka

tatarduka

    Senior Member

  • Grup: Senior Members
  • Posts: 3,042
  • Înscris: 30.10.2006

 modoran, on 06 noiembrie 2017 - 09:37, said:

Mie niciodata nu mi-au placvut API-urile cu fisiere in mod asincron. Daca ai nevoie de asa ceva iti creezi propriul thread si folosesti tot API-urile sincrone.
Singura problema e ca daca vrei performanta, creerea/distrugerea unui thread are un cost destul de mare. De aceea se tin intr-un pool si nu se fac/distrug nonstop thread-uri.

 Sess, on 06 noiembrie 2017 - 07:16, said:

Intrebarea mea este: urmatorul job pe care il preia, nu trebuie trimis tot kernelului spre procesare, si atunci nu trebuie sa astepte finalizarea primului job, deci tot un fel de "wait state" ca in cazul synchronous I/O?
Ba da... dar de regula operatiile nu blocheaza kernel-ul. De exemplu daca tu vrei sa scrii date intr-un fisier, kernel-ul o sa zica mai departe unui controller DMA: "muta datele astea si anunta-ma cand esti gata". Deci nu are rost sa tii blocat un thread, cand poate sa se ocupe de altceva pana DMA-ul termina cu transferul datelor. De altfel, exista multe controllere DMA si oricum kernel-ul probabil face o coada cu ce are de facut si le sincronizeaza in functie de cate resurse hardware are la dispozitie.

Edited by tatarduka, 06 November 2017 - 11:39.


#11
NANDdiscovery

NANDdiscovery

    New Member

  • Grup: Junior Members
  • Posts: 18
  • Înscris: 06.11.2017

 _Smiley_, on 06 noiembrie 2017 - 08:14, said:

un job poate fi si urmarirea tastaturii si reactia la apasarea unei taste.
Notiune de job se refera in general la actiuni finite  in timp. Tu ai dat insa exemplu de un watchdog.Practic atat timp cat kernelul este alive acel watchdog al tastaturii va verifica la intervale de timp
presecrise daca exista o schimbare de configuratie  in bufferul tastaturii, iar acest watchdog nu va termina niciodata ci va sta in memorie atat timpul cat si kernelul este in viata.
Jobul insa , porneste, isi face treaba si apoi se opreste fie cu succes fie cu eroare si nu sta in memorie atat timp cat kernelul este in viata.
Dpdv al arhitecturii software (dar si hardware) jobul este totul diferit de watchdog

Edited by NANDdiscovery, 06 November 2017 - 12:53.


#12
NANDdiscovery

NANDdiscovery

    New Member

  • Grup: Junior Members
  • Posts: 18
  • Înscris: 06.11.2017

 Sess, on 06 noiembrie 2017 - 07:16, said:

Salut,

Citeam acest articol: https://msdn.microso...3(v=vs.85).aspx despre sync vs async I/O.

In asynchronous I/O spune ca un thread primeste un request I/O si acesta este trimis kernelului spre procesare, iar in acest timp, preia alt job.

Intrebarea mea este: urmatorul job pe care il preia, nu trebuie trimis tot kernelului spre procesare, si atunci nu trebuie sa astepte finalizarea primului job, deci tot un fel de "wait state" ca in cazul synchronous I/O?
Aici intra in scena HAL-ul (Hardware Abstraction Layer), care ii spune kernelului cum ar trebui sa trateze cererea de I/O. Problema este ca uneori kernelul se poate comporta cum ai intuit si tu,
alteori nu. De ce acesta ciudentie ? Well, in mod indirect din cauza modului de proiectare a hardware-ului pe care HAL il acceseaza.
Exemplu: daca  cererea de scriere I/O a unui fisier este trimisa prin HAL  catre un device de scriere , al carui firmware accepta doar operatii I/O sincrone , atunci cererea ta asincrona va fi segmentata in mai multe cereri sincrone si puse in bufferul de asteptare(I/O Bufffering)  de catre Kernel.
Daca firmware-ul device-ului accepta operatii asincrone de I/O atunci kernelul va umple bufferul de asteptare  insa cu cereri asincrone.

Edited by NANDdiscovery, 06 November 2017 - 13:06.


#13
karax

karax

    Guru Member

  • Grup: Senior Members
  • Posts: 21,839
  • Înscris: 14.10.2017

 cspot, on 06 noiembrie 2017 - 09:24, said:

Procesorul executa un numar de threaduri simultan. Mai exact doar un singur thread este executat la un moment dat pentru o perioada limitata de timp.
In cazul unui program care vrea sa citeasca ceva de pe HDD cererea este trimisa catre HDD si apoi se asteapta raspunsul. Hdd-ul nu va raspunde imediat. Cautarea si citirea datelor de care ai nevoie necesita timp. Citirea se face rapid, dar in timpul asta procesorul sta de pomana.
Ca atare, programul tau va consuma timp de procesor de pomana. In cazul citirii asyncrone se face cererea catre HDD iar colectarea datolor citite se face ulterior cand acestea sunt disponibile. In timpul asta programul poate sa execute altceva sau poate sa nu execute nimic. Procesorul va avea timp sa execute alte threaduri.
A da am scos HDD-ul din ecuatie, care HDD fiind un dispozitiv mecanic normal ca are viteza redusa. Deci procesorul depinde de HDD. Bun deci sa inteleg ca cea mai importanta si mai importanta parte a unui procesor intr-un fel este memoria cache care poate stoca date ce pot fi transmise inapoi la HDD dupa ce s-a ocupat procesorul. Cu cat mai multe date in memoria cache cu atat mai mult timp va putea lucra procesorul fara sa ia din HDD date, astfel ajungandu-se la un moment in care bufferul procesorului permite HDD-ului sa aiba un timp pentru a putea citi urmatoarele chestii si astfel lucrul sistemului sa para continuu.

 tatarduka, on 06 noiembrie 2017 - 11:33, said:

Singura problema e ca daca vrei performanta, creerea/distrugerea unui thread are un cost destul de mare. De aceea se tin intr-un pool si nu se fac/distrug nonstop thread-uri.


Ba da... dar de regula operatiile nu blocheaza kernel-ul. De exemplu daca tu vrei sa scrii date intr-un fisier, kernel-ul o sa zica mai departe unui controller DMA: "muta datele astea si anunta-ma cand esti gata". Deci nu are rost sa tii blocat un thread, cand poate sa se ocupe de altceva pana DMA-ul termina cu transferul datelor. De altfel, exista multe controllere DMA si oricum kernel-ul probabil face o coada cu ce are de facut si le sincronizeaza in functie de cate resurse hardware are la dispozitie.
Dar nu conteaza si care date sunt esentiale pentru rularea smooth a calculatorului? Banuiesc ,simplist vorbind, ca daca ocupi procesorul cu requesturi sa se ocupe de sa zicem deschis si inchis niste ferestre , muzica pe care o ai pornita in acel moment va primi o prioritate low desi tu pui in momentul ala pe prim plan ascultatul de muzica. Deci nu e mai bine sa se mearga pe principiul "primul program primit , primul servit"? Exceptand cazurile cand un alt program deschis ar afecta kernelul si implicit playerul de muzica pe care te conentrezi , caz in care probabilca impartirea trebuie facuta cat mai precis in procente pentru ca toate aplicatiile sa aiba loc. De altfel exista programe de verificat load-ul cpu-ului si al ram-ului si poti testa cu diferite programe cat cer impreuna si separat fiecare.

 NANDdiscovery, on 06 noiembrie 2017 - 12:44, said:

Notiune de job se refera in general la actiuni finite  in timp. Tu ai dat insa exemplu de un watchdog.Practic atat timp cat kernelul este alive acel watchdog al tastaturii va verifica la intervale de timp
presecrise daca exista o schimbare de configuratie  in bufferul tastaturii, iar acest watchdog nu va termina niciodata ci va sta in memorie atat timpul cat si kernelul este in viata.
Jobul insa , porneste, isi face treaba si apoi se opreste fie cu succes fie cu eroare si nu sta in memorie atat timp cat kernelul este in viata.
Dpdv al arhitecturii software (dar si hardware) jobul este totul diferit de watchdog
Exact cam ce vroiam sa arat

 NANDdiscovery, on 06 noiembrie 2017 - 13:05, said:

Aici intra in scena HAL-ul (Hardware Abstraction Layer), care ii spune kernelului cum ar trebui sa trateze cererea de I/O. Problema este ca uneori kernelul se poate comporta cum ai intuit si tu,
alteori nu. De ce acesta ciudentie ? Well, in mod indirect din cauza modului de proiectare a hardware-ului pe care HAL il acceseaza.
Exemplu: daca  cererea de scriere I/O a unui fisier este trimisa prin HAL  catre un device de scriere , al carui firmware accepta doar operatii I/O sincrone , atunci cererea ta asincrona va fi segmentata in mai multe cereri sincrone si puse in bufferul de asteptare(I/O Bufffering)  de catre Kernel.
Daca firmware-ul device-ului accepta operatii asincrone de I/O atunci kernelul va umple bufferul de asteptare  insa cu cereri asincrone.
yep si daca conectezi mai multe deviceuri iese o varza. Asta pare o chestiune de statistica si probabilitai.

#14
dani.user

dani.user

    Guru Member

  • Grup: Senior Members
  • Posts: 30,194
  • Înscris: 24.02.2007
In cazul Windows ai IO completion port unde initiezi diverse operatii asincrone (citire de pe disc/retea, etc) si apoi definesti unul sau mai multe threaduri ce sa primeasca raspunsul, indiferent de cate operatii se desfasoara in acel timp.

Multi cand aud de asincron se gandesc ca trebuie sa creeze 1 thread/operatie, o adevarata risipa de resurse.

Anunturi

Chirurgia spinală minim invazivă Chirurgia spinală minim invazivă

Chirurgia spinală minim invazivă oferă pacienților oportunitatea unui tratament eficient, permițându-le o recuperare ultra rapidă și nu în ultimul rând minimizând leziunile induse chirurgical.

Echipa noastră utilizează un spectru larg de tehnici minim invazive, din care enumerăm câteva: endoscopia cu variantele ei (transnazală, transtoracică, transmusculară, etc), microscopul operator, abordurile trans tubulare și nu în ultimul rând infiltrațiile la toate nivelurile coloanei vertebrale.

www.neurohope.ro

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Forumul Softpedia foloseste "cookies" pentru a imbunatati experienta utilizatorilor Accept
Pentru detalii si optiuni legate de cookies si datele personale, consultati Politica de utilizare cookies si Politica de confidentialitate