Fórum Root.cz
Hlavní témata => Vývoj => Téma založeno: Vertex 12. 08. 2015, 16:41:55
-
Zdravim,
vie mi niekto polopate vysvetlit na čo sú dobré generátory v JS? Prečítal som niekoľko článkov a stále mi vôbec nie je jasné čo to má ako byť.
Argumentuje sa, že to zabráni callback hell, ale mne to príde, že namiesto callback hell tam teraz bude generator hell. Okrem toho pri použíti
generátorov mi vôbec nie je jasné ako aplikácia prebieha, kedy sa čo vykoná, pri callbackoch sa mi o tom uvažuje oveľa jednoduchšie.
Ďakujem.
-
na čo sú dobré generátory v JS?
V podstatě se můžete dostat k vymezené kontinuaci (angl. delimited continuation), která jde použít nejvýše jednou a nemůže předat hodnotu zpět do funkce (next nebere žádný argument). Když píšete callbacky, musíte udělat podobnou transformaci ručně - u generátorů to udělá prohlížeč za vás.
Yield si můžete představit jako throw (tj. příkaz vyhazující výjimku), s tím rozdílem, že se později po vyhození a odchycení výjimky můžete vrátit za místo, kde byla výjimka vyhozena (za příkaz throw), a pokračovat v běhu. Mj. napsal jsem článek Algebraické efekty (http://www.abclinuxu.cz/blog/radekm/2015/6/algebraicke-efekty) - netýká se však pouze generátorů (generátory jsou pouze speciálním případem algebraických efektů).
Okrem toho pri použíti generátorov mi vôbec nie je jasné ako aplikácia prebieha, kedy sa čo vykoná
IMO dá se na to zvyknout.
-
jednou a nemůže předat hodnotu zpět do funkce (next nebere žádný argument)
To se mělo týkat pouze iterátorů, jinak samozřejmě next bere argument, jinak by asynchronní volání nemohly nic vracet.
-
Generatory v JS neznam, takze to ber s rezervou, na zaklade moji zkusenosti s Pythonem, ktery ma generatory.
Myslim, ze hlavni vyhodou je, ze nemusis umele delit kod do dvou funkci (treba asynchronni volani a callback), ale muzes je dat do jednoho bloku. To zprehlednuje kod, protoze nemusis preskakovat pri cteni do te druhe funkce. Je to tedy v podstate vyjadrenim myslenky, ze sekvencni kod, ktery spolu souvisi, by mel byt definovany v ramci jedne funkce nebo procedury.
-
vie mi niekto polopate vysvetlit na čo sú dobré generátory v JS?
Generátor ušetří neustálé předávání callbacku do funkce, automaticky se uvažuje že callback je na kód následující za NEXT a tento automatický callback se používá YIELD.
Mimo to má callback vlastní stack i lokální proměné existující po celou dobu existence generátoru, takže se s tím dají dělat zajímavé věci, trochu to připomíná kooperativní vlákna. Kód generátoru se tak dá pozastavit tím YIELD a pak se vrátit a pokračovat.
asynchronni volani
asynchronní volání
V JS nic takového jako asynchronní volání neexistuje, všechno co je zapsáno v javascriptu je bezvýhradně synchronní.
-
V JS nic takového jako asynchronní volání neexistuje, všechno co je zapsáno v javascriptu je bezvýhradně synchronní.
Co tedy určuje třetí parametr async u XMLHttpRequest.open (https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest#open%28%29)?
Rovněž handlery událostí jsou spouštěny asynchroně.
-
async znamená že kód mimo JS, obvykle v C/C++, skutečně běží asynchronně.
Handlery událostí jsou ovšem spouštěny synchronně s ostatními funkcemi, například handler od timeru není spuštěn tehdy kdy má, ale až se ostatní funkce milostivě uráčí skončit, to je v rozporu s asynchronicitou.
-
async znamená že kód mimo JS, obvykle v C/C++, skutečně běží asynchronně.
Podstatné je, že po dobu provádění požadavku může aplikace provádět jinou činnost a nezatuhne. Kdyby to bylo synchronní, tak by aplikace (přesněji volající vlákno - jenže v JS máte obvykle jedno vlákno) zatuhla (např. by nezpracovávala žádné událost), dokud by požadavek neskončil. Je irelevantní, jak je to implementováno.
Handlery událostí jsou ovšem spouštěny synchronně s ostatními funkcemi, například handler od timeru není spuštěn tehdy kdy má, ale až se ostatní funkce milostivě uráčí skončit, to je v rozporu s asynchronicitou.
Mám na mysli skutečnost, že vyhození události např. pomocí setInterval(f, 0) nezpůsobí zablokování volajícího kódu, dokud událost není zpracována (dokud f nedoběhne).
-
Antonymum synchronní není neblokující. setInterval(f, 0) je neblokující, ale ne asynchronní, kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
-
Antonymum synchronní není neblokující. setInterval(f, 0) je neblokující, ale ne asynchronní, kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
-
Nejsem velkým znalcem (ani příznivcem) akademické terminologie, ale pokud aspoň lehce kouknu do wikipedie na heslo asynchronní, které není v rozporu jak asynchronnost za ta léta chápu já, nevidím tam jedinou zmínku o současném (paralelním) vykonávaní. Naopak, naprosto v souladu s chápáním synchronních (taktovaných) a asynchronních elektrických obvodů se bavíme o tom, kdy může přijít požadavek. Zda bude zpracován pomocí preemptivního (přerušení, priority) nebo kooperativního multitaskingu (eventloop - až bude volno) je jen implementační detail.
-
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Všude tam kde mají preemptivní multithreading, ve smyslu jak je to známo třeba z C#.
Naopak, naprosto v souladu s chápáním synchronních (taktovaných) a asynchronních elektrických obvodů se bavíme o tom, kdy může přijít požadavek. Zda bude zpracován pomocí preemptivního (přerušení, priority) nebo kooperativního multitaskingu (eventloop - až bude volno) je jen implementační detail.
To právě není detail, příjem znaků z asynchronní sériové linky musíte zpracovat přiměřeně rychle, ne až nějaký hlupák dokončí pětiminutový výpočet a uvolní tak eventloop, to už budou znaky nenávratně ztraceny.
-
v jeden čas by tak běžely dvě funkce najednou
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Všude tam kde mají preemptivní multithreading, ve smyslu jak je to známo třeba z C#.
ale na jednoprocesorovém systému nepoběží obě funkce naráz, jsou tedy nutné alespoň dva procesory, ano?
-
tedy asynchronnost lze realizovat pouze na víceprocesorovém (vícejádrovém) systému?
Všude tam kde mají preemptivní multithreading, ve smyslu jak je to známo třeba z C#.
kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
Mj., momentální implementace asynchronních operací v .NET Frameworku (tj. i C#) rovněž nezaručuje, že se asynchronní operace začne vykonávat bezprostředně (např., když jsou všechna vlákna ve ThreadPoolu obsazená). A řada jiných implementací je na tom podobně.
Antonymum synchronní není neblokující.
Právě bych řekl, že ano. Jinak řečeno synchronní a blokující je totéž (alespoň já to tak chápu) - viz třeba Wikipedie (https://en.wikipedia.org/wiki/Asynchronous_I/O): But such an approach (called synchronous I/O or blocking I/O) would block the progress of a program while the communication is in progress.
-
Vysvětlím polopaticky, máme funkci FOO pět minut počítající FFT, mezitím přijdou data ze soketu, takže se ihned vyvolá asynchronně funkce BAR a zcela nezávisle na FOO data zobrazí na monitoru. Bez asynchronnosti by se funkce BAR zavolala až po skončení FOO, přesně tak jako se to děje v JS.
Myslím že už jsem to vysvětlil dostatečně. (Uvedené chování jde zajistit i na jednoprocesorovém stroji)
-
Zdravim,
chcem vám všetkým poďakovať za vaše odpovede. Už mi je to jasnejšie. Ešte sa s tým pohrám aby sa mi to dostalo do krvi.
Vďaka.
-
Vysvětlím polopaticky, máme funkci FOO pět minut počítající FFT, mezitím přijdou data ze soketu, takže se ihned vyvolá asynchronně funkce BAR a zcela nezávisle na FOO data zobrazí na monitoru. Bez asynchronnosti by se funkce BAR zavolala až po skončení FOO, přesně tak jako se to děje v JS.
Myslím že už jsem to vysvětlil dostatečně. (Uvedené chování jde zajistit i na jednoprocesorovém stroji)
Ale my vám rozumíme :), není potřeba to vysvětlovat polopatisticky. Jen nesouhlasíme s vaší definicí (pojetím) toho, co je asynchronní... :D
A jen tak mimochodem, i ten výpočet FFT lze triviálně napsat tak, že bude obsluhovat příchozí požadavky rychleji než to zvládne preemptivní multitasking, který tak propagujete. Změníte pak svou definici asynchronosti?
-
Vysvětlím polopaticky, máme funkci FOO pět minut počítající FFT, mezitím přijdou data ze soketu, takže se ihned vyvolá asynchronně funkce BAR a zcela nezávisle na FOO data zobrazí na monitoru. Bez asynchronnosti by se funkce BAR zavolala až po skončení FOO, přesně tak jako se to děje v JS.
Myslím že už jsem to vysvětlil dostatečně. (Uvedené chování jde zajistit i na jednoprocesorovém stroji)
zřejmě používáte nějakou definici současnosti se kterou nejsem obeznámený
-
zřejmě používáte nějakou definici současnosti se kterou nejsem obeznámený
Používám definici, která je poměrně obecně přijímána (pokud se bavíme o synchronních/asynchronních voláních v oblasti SW) a je stručně popsána takto:
When you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes.
Toto je taky relevantní k původnímu dotazu.
-
When you execute something asynchronously, you can move on to another task before it finishes.
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Jistě se to nedá pochopit tak, že se čeká pět minut až volající dá pokoj a pak teprve se zavolá something.
-
zřejmě používáte nějakou definici současnosti se kterou nejsem obeznámený
Používám definici, která je poměrně obecně přijímána (pokud se bavíme o synchronních/asynchronních voláních v oblasti SW) a je stručně popsána takto:
When you execute something synchronously, you wait for it to finish before moving on to another task. When you execute something asynchronously, you can move on to another task before it finishes.
Toto je taky relevantní k původnímu dotazu.
"současností" jsem narážel na toto:
Antonymum synchronní není neblokující. setInterval(f, 0) je neblokující, ale ne asynchronní, kdyby býval byl setInterval(f, 0) asynchronní, potom by k zahájení vykonávání f došlo bezprostředně a v jeden čas by tak běžely dvě funkce najednou a to v JS není možné.
resp. na to, že funkce "běží najednou", proto neustále melu o více procesorech, jestli funkce mohou běžet "najednou" na jednom procesoru, tak můžou i v javascriptu a tím i asynchronně dle k-ovy definice
-
When you execute something asynchronously, you can move on to another task before it finishes.
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Jistě se to nedá pochopit tak, že se čeká pět minut až volající dá pokoj a pak teprve se zavolá something.
takže hardwarové přerušení není asynchronní, protože po přiřazení handleru se ten nevykoná okamžitě?
-
Hardware do toho nemotejte, to se tu už důkladně diskutovalo http://forum.root.cz/index.php?topic=11249.msg132438#msg132438 a v zásadě to skončilo, že jedna strana diskutujících uvažovala v rámci hw a druhá v rámci virtuálního stroje (např. jvm).
Celé nedorozumění v případě javascriptu jednoduše spočívá v tom, že lidé zaměňují odložené spuštění (zařazení do fronty úloh) a paralelní běh (současný běh více položek z té fronty), část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti. Navíc celý systém callbacků budí dojem, že si žijí svým vlastním životem a že to celé „běží tak nějak naráz“. S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým. Alespoň v prohlížeči - nevím jak to je v případě node.js a spol, tam je asi možné ledacos.
-
část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti
Pokud nečekáte na výsledek, tak samozřejmě je.
-
Pokud bych to bral, jako že u asynchronního běhu není přesně dáno, kdy se úloha zadaná k provedení skutečně začne vykonávat a na tento začátek se nečeká, pak by bylo jedno, jak moc paralelně to probíhá. A pak by mě zajímalo, proč některým vadí, že něco něběží +-skutečně paralelně. Že by to byl klasicky zase jen problém definice?
-
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Nevyplyva. Na toto tema je dobra prednaska http://blog.golang.org/concurrency-is-not-parallelism (http://blog.golang.org/concurrency-is-not-parallelism). Asynchronni volani jsou forma concurrency, k paralelismu muze dojit ale nemusi (jak uz tu nekdo zminil HW interrupt na jednom procesoru je dobry priklad). Stejne tak existuje paralelismus bez concurrency, typicke priklady jsou pipelining nebo SIMD.
Jistě se to nedá pochopit tak, že se čeká pět minut až volající dá pokoj a pak teprve se zavolá something.
Myslim, ze duvod tveho nepochopeni (krome vyse uvedeneho) je v tom, ze to co ostatni (Radek) zde oznacuji za asynchronni volani neni nutne zapsano podobne jako synchronni volani funkce(parametr), ale provadi se to prave predanim callback rutiny. Skoro kazdy jazyk umoznuje "asynchronni volani" v tomto smyslu, aniz by vyzadoval specialni syntaxi.
-
Normální člověk tohle pochopí tak, že operace something se zahájí bezprostředně ihned a volající nečeká na její dokončení a může si mezi tím dělat svoje věci, implicitně z toho vyplývá paralelní běh.
Nevyplyva.
Tímto s Vámi končím, nejste normální a nebudu s Vámi dál ztrácet čas.
Přednáška s chybou již v názvu mě nezajímá.
Celé nedorozumění v případě javascriptu jednoduše spočívá v tom, že lidé zaměňují odložené spuštění (zařazení do fronty úloh) a paralelní běh (současný běh více položek z té fronty), část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti. Navíc celý systém callbacků budí dojem, že si žijí svým vlastním životem a že to celé „běží tak nějak naráz“. S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým.
Ano, souhlas.
-
Přednáška s chybou již v názvu mě nezajímá.
Paralelní != konkurentní (https://existentialtype.wordpress.com/2011/03/17/parallelism-is-not-concurrency/) není chyba (většina lidí se například shodne na tom, že konkurentní neimplikuje paralelní).
-
Celé nedorozumění v případě javascriptu jednoduše spočívá v tom, že lidé zaměňují odložené spuštění (zařazení do fronty úloh) a paralelní běh (současný běh více položek z té fronty), část z nich si pak myslí, že odložené spuštění je znakem asynchronnosti. Navíc celý systém callbacků budí dojem, že si žijí svým vlastním životem a že to celé „běží tak nějak naráz“. S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým.
Zajímavé... argumentujeme zde o tom "co si někteří myslí" a nebo co asynchronní odpravdu znamená? A co je tedy odložení spuštění jiného než jedna z možných implementací asynchronicity?
Já měl za to že asynchronní znamená že prostě není synchronní (tj. že když danou část programu zavolám tak nemám jistotu že dokud nedoběhne tak se nic jiného nestane - nepočítejme pro zjednodušení vnější vstupy), a jestli je to tím že to běží po sobě v předem nedefinovaném pořadí (odloženě), nebo paralelně na tom samém stroji a nebo někde na serveru je z pohledu synchronní/nesynchronní irelevantní implementační detail (který se navíc může u jednotlivých instancí programu lišit podle toho na čem zrovna běží).
-
S vyjímkou volání ajaxu ale všechno v javascriptu běží pěkně jedno za druhým. Alespoň v prohlížeči - nevím jak to je v případě node.js a spol, tam je asi možné ledacos.
S tim nemohu souhlasit. Staci stranka, ktera ma dva GUI prvky navazane na Javascript - pak neni vubec jasne, ktery kod se vykona driv, protoze to zalezi na tom, kam uzivatel zrovna klikne. Takze je vysledny program asynchronni, prestoze tim uzivatelem muze byt pomala babicka, ktera vsechno provadi v podstate synchronne.
Neco jineho je CGI skript nebo tzv. inteligentni terminal - ty jsou synchronni - uzivatel zada data, stiskne ENTER a server zpracuje pozadavek (a uzivatel musi cekat, dokud se nevrati odpoved).
-
aby som prispel troškou bordelu, aj ajax sa dá spraviť synchrónne, čiže už to vlastne ani nie je ajax, ale sjax :)
-
Tyhle diskuse mne docela baví... :D
Jak už jsem psal někde v počátcích, problém je v definicích a zjednodušování, proto jsem přihodil definici toho, co myslím asynchronností já. A pak tu člověk čte javascript, ale myslí se jen browser, napíše se že veškerý JS běží v jednom vláknu, ale nedodá se že knihovny a IO operace už v tom samém vláknu neběží, a to nemluvím o webworkerech, atd. atd. Když napíšu že na konkurenčním modelu nezáleží, protože je to implementační detail, tak se operuje paralelním během. A nejkomičtější jsou argumenty s pětimintovým čekáním, když v naprosté většině reálných testů a nasazení ten "strašně pomalý" javascript, kde se tak dlouho čeká na odpověď poráží v rychlosti své konkurenty (jako třeba Java) a hlavně má mnohem kratší reakční dobu na požadavek. Právě proto byl také nasazen na webové stránky a jeho asynchronnost (mimochodem, naprostá většina UI je asynchronní na bázi event loopu, aby byla rychlejší doba odezvy) byla jedna z primárních vlastností. A kvůli té "pomalosti" jsou pak do dalších jazyků zapracovávány asynchronní metody volání, vznikají asynchronní frameworky atd., jen proto abychom zpomalili běh programů.... :)
Mimochodem, ta jednovláknost javascriptu je jednou z jeho velkých výhod. Za prvé to zjednodušuje programování při přístupu ke sdíleným zdrojům, za druhé to umožňuje jednoduše a téměř lineárně škálovat výkon s relativně malou spotřebou systémových zdrojů.
-
naprostá většina UI je asynchronní na bázi event loopu
S Vámi také končím, označit event loop asynchronní je již mimo moje chápání.
-
naprostá většina UI je asynchronní na bázi event loopu
S Vámi také končím, označit event loop asynchronní je již mimo moje chápání.
žádný problém, vždyť nikdo nejsme vševědoucí, zkusím vám to vysvětlit na (trošičku vykonstruovaném) příkladu
uživatel klikne na tlačítko, systém zachytí přerušení (to je synchronní zpracování), ale nepodnikde žádnou akci vázanou na funkci tlačítka, ale zprávu uloží do fronty, aplikace kontroluje (v "event loop") jestli něco zmíněnou frontou nepřišlo, pokud ano, podnikne příslušné kroky, tedy pokud se jí to hodí a kdy se jí to hodí - asynchronně vzhledem ke vzniku události
-
(a)synchronní, (ne)blokující, paralelní, konkurenční, preemptivní, ... vyzná se v tom ještě někdo?
-
(a)synchronní, (ne)blokující, paralelní, konkurenční, preemptivní, ... vyzná se v tom ještě někdo?
Vyzna:
(a)synchronní => udalost
(ne)blokující => volani
paralelní => hardware
konkurenční => software
preemptivní => planovac
Jsou to pribuzne koncepty, jen se kazdy vztahuje na neco jine. ;)
-
To jste do toho zamotal přerušení a zamotal jste i sebe :) Vyvolání obsluhy IRQ je asynchronní záležitost, fronta událostí je synchronní záležitost, event-loop též synchronní záležitost. Asynchronní obsluhu události od IRQ si můžete představit jako pohyb myši, zjevně se hybá i když event-loop zrovna dělá něco jiného.
-
To jste do toho zamotal přerušení a zamotal jste i sebe :)
Jediny, kdo se tady zamotava jste vy:
Vyvolání obsluhy IRQ je asynchronní záležitost
Urcite? Podle vasi analogie je to take synchronni, protoze vyvolani IRQ je rizene synchronnim hodinovym signalem procesoru...
Pointa je, ze asynchronost je urcita abstrakce reality, nikoli realita. Plynuti casu z hlediska aplikace muze vypadat jinak nez z hlediska operacniho systemu, asi podobne jako nahodny generator nemusi byt nutne realne nahodny (v deterministickem vesmiru se to treba zaridi tezko), staci nahodny z pohledu aplikace.
-
Fronta událostí n. operací je (resp. může být pokud povoluje pouze seriání zpracování) sychronní vzhledem sama k sobě, ale nikoli vzhledem k provádění kódu který do ní události/operace vkládá.
-
To jste do toho zamotal přerušení a zamotal jste i sebe :)
vy, abyste se nezamotal, námitky ignorujete - co je to ten současný běh funkcí?
Vyvolání obsluhy IRQ je asynchronní záležitost
přerušení je vyvoláno asnychronně - uživatel klikne kdy se rozhodne, ale kód ISR se provádí okamžitě, za přerušení provádění původního programu, jehož vykonávání pokračuje až to ISR s tím kliknutím dořeší
fronta událostí je synchronní záležitost
fronta události je datová struktura
event-loop též synchronní záležitost
"event loop" je konstrukce v programu pro zpracování asynchronně vznikajích událostí, události jsou vyhodnocovány až se program usmyslí, ne okamžitě kdy vzniknou
Asynchronní obsluhu události od IRQ si můžete představit jako pohyb myši, zjevně se hybá i když event-loop zrovna dělá něco jiného.
já jsem mluvil o kliknutí a aplikaci, ale pokud chcete naznačit, že různé události se mohou zpracovat různými postupy, tak asi máte pravdu
-
vy, abyste se nezamotal, námitky ignorujete - co je to ten současný běh funkcí?
Přerušení do toho zamotalo ISR a tím se nám to zkomplikovalo :) Řeč byla o asynchronním vykonávání funkcí v rámci jedné aplikace. Současný běh funkcí logicky je že v jednom čase se vykonávají dvě funkce a nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první. Technicky se to nejčastěji realizuje pomocí vláken nebo procesů.
přerušení je vyvoláno asnychronně
"event loop" je konstrukce v programu pro zpracování asynchronně vznikajích událostí, události jsou vyhodnocovány až se program usmyslí, ne okamžitě kdy vzniknou
To se shodujeme :) ISR je asynchronní, vloží událost do fronty událostí a tím asynchronní obsluha události skončila.
Když má event-loop čas, tak vybere událost z fronty událostí a jednu po druhé synchronně zpracuje, v jeden čas se zpracovává pouze jedna událost.
já jsem mluvil o kliknutí a aplikaci, ale pokud chcete naznačit, že různé události se mohou zpracovat různými postupy, tak asi máte pravdu
Ano můžete si vybrat:
A) Událost od kliknutí na tlačítko myši vložit do fronty a událost se zpracuje synchronně vůči všem ostatním událostem.
B) Událost od pohybu myší obsloužit rovnou v ISR a pak se zpracuje asynchronně vůči všem ostatním událostem ve frontě.
-
Současný běh funkcí logicky je že v jednom čase se vykonávají dvě funkce
teď fakt nevím, jestli žertujete
-
Současný běh funkcí logicky je že v jednom čase se vykonávají dvě funkce a nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první.
Není to nutný předpoklad - funkce se mohou střídat (tj. v jednom čase poběží pouze jedna) nebo se jedna z funkcí začne vykonávat až poté, co jiná skončí.
-
(a)synchronní, (ne)blokující, paralelní, konkurenční, preemptivní, ... vyzná se v tom ještě někdo?
Vyzna:
(a)synchronní => udalost
(ne)blokující => volani
paralelní => hardware
konkurenční => software
preemptivní => planovac
Jsou to pribuzne koncepty, jen se kazdy vztahuje na neco jine. ;)
Hmm, to by dávalo smysl.
-
...
konkurenční => software
...
jen dotaz - já vždy používám výraz "konkurentní", je "konkurenční" v daném kontextu OK oboje?
-
...
konkurenční => software
...
jen dotaz - já vždy používám výraz "konkurentní", je "konkurenční" v daném kontextu OK oboje?
doporučuju: http://prirucka.ujc.cas.cz
řekl bych, že "konkurentní" je zkomolenina
-
teď fakt nevím, jestli žertujete
Také fakt nevím, co na tom pořád nechápete.
nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první.
Není to nutný předpoklad - funkce se mohou střídat (tj. v jednom čase poběží pouze jedna) nebo se jedna z funkcí začne vykonávat až poté, co jiná skončí.
Člověk to tady může psát celý den, že takhle to nejde, ale je to marný, je to marný, je to marný. Tímto končím definitivně.
https://www.youtube.com/watch?v=XDJEPjvbbs4
-
...
doporučuju: http://prirucka.ujc.cas.cz
řekl bych, že "konkurentní" je zkomolenina
Jj, máš asi pravdu, "konkurentní" vypadá na programátorskou čengliš.
"Konkurenční" mi ale zase v daném kontextu přijde, jako když v češtině někdo používá "pregnantní" ve významu anglického "pregnant".
Se zkusim přešaltovat na "souběžný" a tu čengliš ze slovníku vyřadit. :-)
-
nutný nikoliv postačující předpoklad k tomu je, že druhá funkce nečeká na dokončení první.
Není to nutný předpoklad - funkce se mohou střídat (tj. v jednom čase poběží pouze jedna) nebo se jedna z funkcí začne vykonávat až poté, co jiná skončí.
Člověk to tady může psát celý den, že takhle to nejde, ale je to marný, je to marný, je to marný. Tímto končím definitivně.
https://www.youtube.com/watch?v=XDJEPjvbbs4
Že to píšete celý den, neznamená, že to tak je.
-
Tímto končím definitivně.
To je dobre, kdyz se ignorantum jako vy (kteri se nechteji nic noveho dozvedet) snazi zde nekteri vzdelani lide (Radek) neco vysvetlit, jde opravdu o zbytecnou namahu.
-
Jak to chápu:
(a)synchronní znamená, že nějaké dvě věci spolu jsou nebo nejsou sesynchronizovány. Takže když mám dvě zavolání funkcí, jedna zpracovává svůj výsledek déle než druhá, tak není přihlíženo na pořadí volání, ale na délku vykonávání té funkce.
(ne)blokující znamená, že jedna věc (ne)blokuje jinou. Například zavolám první funkci, a hned mohu volat druhou a nemusím čekat na výsledek, protože ten výsledek se mi zpět dopraví jiným způsobem (callbackem).
paralelní znamená, že dvě funkce se vykonávají ve stejný čas (reálně, na více jádrech, ale platí to i když to je jen iluzojní pomocí multitaskingu).
Vychází mi z toho, že často se děje kombinace neblokující asynchronní volání funkce, a když jich zavolám více, tak budou spolu běžet paralelně. Ale neimplikuje to nutnost. Klidně můžu zavolat dvě funkce neblokujíce (s callbackem), oni se mi na sobě nezávisle zavolají (to znamená, že nemám zaručeno, která se spustí první), ale z nějakého implementačního důvodu (http://devel.cz/otazka/async-immutable) se spustí za sebou - takže nejsou paralelní.
Stejně tak bych, když bych se hodně snažil, určitě našel i případ, kdy budu mět asynchronní, blokující, neparalelní...
Správně?