Asinhronost

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?

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

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?

jype je 19. nov 2012 ob 21:12 izjavil:

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.

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.

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.