Forum » Programiranje » Asinhronost
Asinhronost
Isotropic ::
tisti asynchroneous programming (al neki takega), k je sedaj na veliko zastopan v .net, ko so napisali, da so se programerji slepali dost cajta.
je to multithreading (za obicajne programe, recimo racunanje, izris gui, pisanje v datoteko...) al nekaj drugega?
je to multithreading (za obicajne programe, recimo racunanje, izris gui, pisanje v datoteko...) al nekaj drugega?
Spura ::
tisti asynchroneous programming (al neki takega), k je sedaj na veliko zastopan v .net, ko so napisali, da so se programerji slepali dost cajta.
je to multithreading (za obicajne programe, recimo racunanje, izris gui, pisanje v datoteko...) al nekaj drugega?
Asinhronost samo pomeni da trenutna nit preda nadaljevanje operacije drugi niti in nadaljuje izvajanje.
Isotropic ::
se pa izvajata obe paralelno ane? lahko tut na vecih corih?
ce prav razumem, je to tist, ko oddas pisanje v file drugemu threadu, da ni tacajt program locked-up.
edit zgleda da ne
kaj so pa poj prednosti takega nacina programiranja?
ce prav razumem, je to tist, ko oddas pisanje v file drugemu threadu, da ni tacajt program locked-up.
edit zgleda da ne
In this model, the tasks are interleaved with one another, but in a single thread of control. This is simpler
than the threaded case because the programmer always knows that when one task is executing, another
task is not. Although in a single-processor system a threaded program will also execute in an interleaved
pattern, a programmer using threads should still think in terms of Figure 2, not Figure 3, lest the program
work incorrectly when moved to a multi-processor system. But a single-threaded asynchronous system will
always execute with interleaving, even on a multi-processor system.
kaj so pa poj prednosti takega nacina programiranja?
Spura ::
Ne vem kaj zdej ti to en primer imas. Je pa tko, da pretiravajo s tem da je multithreaded sistem tezaven kot sto mater. Vecina programerjev razen pri kakih singletonih (razni cachei) ne vidijo kej dosti multithreaded kode, pa cetudi laufajo stvar na kakem sistemu z vecimi threadi (app serverji). Ta asinhronost je pac buzz word du jour.
jype ::
Async je bil tudi dolgo časa standardni način I/O bound programiranja na unixih (in je še vedno prevladujoč).
Isotropic ::
samo kaj bo pa sedaj novost v .net 4.0 (al 4.5, nisem zih) glede tega? kaj se bo s tem pridobilo za programerja/ end userja?
Spura ::
Async je bil tudi dolgo časa standardni način I/O bound programiranja na unixih (in je še vedno prevladujoč).
Ja sej ni nic novega. Samo zdej se folk pretvarja, da je treba cele programe tko pisat because threading is hard and error-prone. (glej node.js)
Ce rabis kje Async, naredis nek event system al pa neki za tist podsistem in to je to.
KrEn1234 ::
samo kaj bo pa sedaj novost v .net 4.0 (al 4.5, nisem zih) glede tega? kaj se bo s tem pridobilo za programerja/ end userja?
Kak mesec nazaj je prišel 4.5. V 4.0 so dodali Task Paralel Library in PLinq.
Prednost zadnje različice je predvsem v tem, da je multi-threading "pristop" vgrajen direktno v programski jezik(V C# npr. await and synchronize). V praksi naj bi to pomenilo, da z samo malenkost bolj kompleksno kodo dobiš več-nitnost. Glede na moje izkušnje se zadeva dobro odnese, res pa, da sem bral nekaj blogov "veteranov", ki se pritožujejo, da je bila zadeva planirana za 5.0 in je posledično nedodelana.
fiction ::
Predlagam fork, ker je tole malo offtopic v temi o plačah.
Asinhrono pomeni samo to, da klicatelj ne čaka na konec operacije. V stilu metoda sproži nek izracun, potem pa preverjaš, če se je tisto končalo ("polling") oz. dobiš povratni klic, ko se konča ("event").
"I/O bound proces" pomeni, da je ozko grlo vhod/izhod, se pravi uporaba večih niti (in posledično več CPU-ja) ne koristi kaj dosti. Tipično narediš pri mrežnem strežniku nek "event loop". V njem preverjaš, če je možno od kakšnega odjemalca kaj prebrati. Če lahko, tisto prebereš in na njegovo zahtevo ustrezno (in hitro) odgovoriš. V ta namen moraš paziti, da branje ne čaka na to, da kaj pride ("non-blocking read"). V primeru da ne, pa preizkusiš še druge povezane odjemalce.
Sočasnih niti je lahko samo toliko kot imaš jeder, sicer se pa to simulira s tem, da nekaj časa teče ena nit potem pa druga. In tak "context-switch" ni čisto zastonj oz. se lahko nabere precej časa, če pretiravaš s številom niti.
Drug (hujši) problem je pa sočasen dostop do pomnilnika, kjer mora biti programer zelo pazljiv. Tekmovalne okoliščine (da je rezultat odvisen od tega, kako so se niti izmenjevale) so težke za odkrit. Program se enkrat v produkciji sesuje, ti pa potem še pol leta ne moreš reproducirati problema. Ponavadi se uporablja medsebojno zaklepanje za dele kode, ampak to je pa spet problematično, ker lahko povzroči smrtni objem ("deadlock").
Pri drugem "načinu" dejansko vedno obravnavaš samo določenega odjemalca in nimaš takih problemov. No s threadi se pa v bistvu dogaja enako, samo da vsaka nit čaka na branju (ker nima nič za prebrat se potem zgodi preklop na drugo nit). Kdaj pa kdaj imaš pa še vedno lahko dve sočasni niti. Kot rečeno node.js je "asinhronost" precej populariziral. Vseeno pa ne verjet raznim zgodbicam o tem, kako je eno ali drugo ful hitrejše in boljše...
Nova buzzworda v C# 5 sta async in await. V bistvu gre samo za neko abstrakcijo, da se človek posveti problemu in ne temu, kako se bo vse skupaj izvajalo. Prej si mel npr. metodo, ki vrača int in izračun traja dolgo časa. Zdaj lahko vrneš Task<int> oz. po Javansko je bolj logično Future<Integer>, nekaj kar bo v prihodnosti številka pa še ni. Ne zafrkavaš se s tem kako oz. v kateri niti se bo izvajal izračun (PLINQ lahko poskrbi, da se bo celo v večih).
No fora awaita (z async samo označiš metodo, ki ima await) je v bistvu to, da se ne pokliče neka druga metoda - izračun je končan, ampak se nadaljuje izvajanje originalne metode, ki npr. to številko spet uporabi za še en povezan kompleksen izračun. Tako imaš vse v zaključeni celoti. Klicatelj ima pa še vedno v rokah "referenco" na "svoj" rezultat.
Bottom line: ne gre za nek nov (še manj pa revolucionaren) pristop, ampak samo za "bombončke", ki ti olajšajo delo.
Asinhrono pomeni samo to, da klicatelj ne čaka na konec operacije. V stilu metoda sproži nek izracun, potem pa preverjaš, če se je tisto končalo ("polling") oz. dobiš povratni klic, ko se konča ("event").
"I/O bound proces" pomeni, da je ozko grlo vhod/izhod, se pravi uporaba večih niti (in posledično več CPU-ja) ne koristi kaj dosti. Tipično narediš pri mrežnem strežniku nek "event loop". V njem preverjaš, če je možno od kakšnega odjemalca kaj prebrati. Če lahko, tisto prebereš in na njegovo zahtevo ustrezno (in hitro) odgovoriš. V ta namen moraš paziti, da branje ne čaka na to, da kaj pride ("non-blocking read"). V primeru da ne, pa preizkusiš še druge povezane odjemalce.
Sočasnih niti je lahko samo toliko kot imaš jeder, sicer se pa to simulira s tem, da nekaj časa teče ena nit potem pa druga. In tak "context-switch" ni čisto zastonj oz. se lahko nabere precej časa, če pretiravaš s številom niti.
Drug (hujši) problem je pa sočasen dostop do pomnilnika, kjer mora biti programer zelo pazljiv. Tekmovalne okoliščine (da je rezultat odvisen od tega, kako so se niti izmenjevale) so težke za odkrit. Program se enkrat v produkciji sesuje, ti pa potem še pol leta ne moreš reproducirati problema. Ponavadi se uporablja medsebojno zaklepanje za dele kode, ampak to je pa spet problematično, ker lahko povzroči smrtni objem ("deadlock").
Pri drugem "načinu" dejansko vedno obravnavaš samo določenega odjemalca in nimaš takih problemov. No s threadi se pa v bistvu dogaja enako, samo da vsaka nit čaka na branju (ker nima nič za prebrat se potem zgodi preklop na drugo nit). Kdaj pa kdaj imaš pa še vedno lahko dve sočasni niti. Kot rečeno node.js je "asinhronost" precej populariziral. Vseeno pa ne verjet raznim zgodbicam o tem, kako je eno ali drugo ful hitrejše in boljše...
Nova buzzworda v C# 5 sta async in await. V bistvu gre samo za neko abstrakcijo, da se človek posveti problemu in ne temu, kako se bo vse skupaj izvajalo. Prej si mel npr. metodo, ki vrača int in izračun traja dolgo časa. Zdaj lahko vrneš Task<int> oz. po Javansko je bolj logično Future<Integer>, nekaj kar bo v prihodnosti številka pa še ni. Ne zafrkavaš se s tem kako oz. v kateri niti se bo izvajal izračun (PLINQ lahko poskrbi, da se bo celo v večih).
No fora awaita (z async samo označiš metodo, ki ima await) je v bistvu to, da se ne pokliče neka druga metoda - izračun je končan, ampak se nadaljuje izvajanje originalne metode, ki npr. to številko spet uporabi za še en povezan kompleksen izračun. Tako imaš vse v zaključeni celoti. Klicatelj ima pa še vedno v rokah "referenco" na "svoj" rezultat.
Bottom line: ne gre za nek nov (še manj pa revolucionaren) pristop, ampak samo za "bombončke", ki ti olajšajo delo.
Spura ::
To moras kr orenk pretiravat da se ti pozna. Cena switchanja med nitmi ni niti priblizno toliksna kot je cena preklopov med procesi v OSu, kar pa folk itak na polno fura.
Sočasnih niti je lahko samo toliko kot imaš jeder, sicer se pa to simulira s tem, da nekaj časa teče ena nit potem pa druga. In tak "context-switch" ni čisto zastonj oz. se lahko nabere precej časa, če pretiravaš s številom niti.
Taki dostopi so dost redki v vecini aplikacij. Recimo tipicen web app itak delas na requestih ki so med seboj neodvisni, zadeva pa laufa multithreaded.
Drug (hujši) problem je pa sočasen dostop do pomnilnika, kjer mora biti programer zelo pazljiv.
In ponavadi je dovolj, da shared podatke vrzes v en class in das en semafor gor na cel class pa basta. Kompleksnejsi scenariji so ful redki.
In dokler imas en lock tut do deadlockov ne more pridet. Jst osebno se nisem nikol imel kode, ki bi drzala vec kot en lock.
S scenariji, kjer je treba res premislit locking, se ponavad clovek sreca ce dela paralelne algoritme cez neke bloke podatkov in ce se odloci za boljso granularnost lockinga (vecje stevilo manjsih lockov, da se niti manj cakajo). V tem primeru ti pa async nic ne pomaga.
noraguta ::
ma async je imutable spremenljivka in lazy evaluacija. ker pa ima OOP kontekstno navezane metode na podatkovne strukture za razliko od funkcijskih jezikov kjer so podtaki vezani na metode(funkcije če čte), je bilo potrebno razširit sintakso jezika. neko bluzenje o unixih, lockih etc je, huh debata za manjšo knjižnico. no razen če vam je zagotavljanje korektne paralelnosti res mačji kašelj,ob enem se vam pa da ukvarjat s kreacijo, uničevanjem in sinhronizacijo niti. tedaj itak vse pohandlate v cju in assemblerju.
Pust' ot pobyedy k pobyedye vyedyot!
mihies ::
fiction je dobro razložil. Da dodam še to, asinhronost je ponavadi najbolj koristna, če imaš aplikacijo vezano na I/O (baze, mrežea, etc) ali pa hočeš ohraniti odziven uporabniški vmesnik.
Precej prav pride tudi pri spletnih aplikacijah (asp.net [MVC]), kjer je število niti omejeno) - če tvoje niti čakajo na nek zunanji dogodek bi strežnik hitro začel zavračati nove povezave. Če pa uporabiš asinhronost potem se asp.net niti sprostijo za nove zahteve. Kar seveda ne pomeni, da bo servisiranje zahtev hitrejše, kvečjemu počasnejše, po drugi strani, bo pa lahko več zahtev bilo hkrati obravnavanih in ljudje ne bodo dobivali napak o zasedenosti strežnika.
async,await ključni besedi ti pa tvoje zaporedno izvajanje spremenijo v asinhrono s tem, da ohranijo isti logični tok dogodkov - npr. poskušaj gnezditi asinhrone klice ali jih tlačiti v zanke in potem še izjeme nadzirat, pa boš razumel, kako dostiš špagetov moraš napisati.
Tako, na hitro.
Precej prav pride tudi pri spletnih aplikacijah (asp.net [MVC]), kjer je število niti omejeno) - če tvoje niti čakajo na nek zunanji dogodek bi strežnik hitro začel zavračati nove povezave. Če pa uporabiš asinhronost potem se asp.net niti sprostijo za nove zahteve. Kar seveda ne pomeni, da bo servisiranje zahtev hitrejše, kvečjemu počasnejše, po drugi strani, bo pa lahko več zahtev bilo hkrati obravnavanih in ljudje ne bodo dobivali napak o zasedenosti strežnika.
async,await ključni besedi ti pa tvoje zaporedno izvajanje spremenijo v asinhrono s tem, da ohranijo isti logični tok dogodkov - npr. poskušaj gnezditi asinhrone klice ali jih tlačiti v zanke in potem še izjeme nadzirat, pa boš razumel, kako dostiš špagetov moraš napisati.
Tako, na hitro.
http://blog.rthand.com/
SLODUG - uporabniška skupina
https://www.facebook.com/groups/slodug/
SLODUG - uporabniška skupina
https://www.facebook.com/groups/slodug/
Vredno ogleda ...
Tema | Ogledi | Zadnje sporočilo | |
---|---|---|---|
Tema | Ogledi | Zadnje sporočilo | |
» | Python primer async/awaitOddelek: Programiranje | 2148 (1254) | jype |
» | [JS] AsinhronostOddelek: Programiranje | 1905 (1373) | GupeM |
» | C# .net class vs .net core async await issueOddelek: Programiranje | 1703 (1463) | detroit |
» | [.NET]asinhrona procedura v web service metodiOddelek: Programiranje | 833 (679) | darkolord |
» | niti (threads) (strani: 1 2 )Oddelek: Programiranje | 5205 (3659) | noraguta |