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 |
Synchronous vs Asynchronous I/O
#1
Posted 06 November 2017 - 07:16
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
Posted 06 November 2017 - 07:24
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
Posted 06 November 2017 - 08:14
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? |
#4
Posted 06 November 2017 - 08:17
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? |
#5
Posted 06 November 2017 - 08:40
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
Posted 06 November 2017 - 08:55
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
Posted 06 November 2017 - 08:55
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? |
#8
Posted 06 November 2017 - 09:24
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
Posted 06 November 2017 - 09:37
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
Posted 06 November 2017 - 11:33
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. 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? Edited by tatarduka, 06 November 2017 - 11:39. |
|
#11
Posted 06 November 2017 - 12:44
_Smiley_, on 06 noiembrie 2017 - 08:14, said:
un job poate fi si urmarirea tastaturii si reactia la apasarea unei taste. 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
Posted 06 November 2017 - 13:05
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? 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
Posted 07 November 2017 - 10:57
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. 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. 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 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. |
#14
Posted 07 November 2017 - 17:43
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
▶ 0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users