Použití Objective-C mimo Apple

[Mirek Prýmek]

nejdřív přesně definujte asynchronnost

Asynchronnost znamená, že proces X pošle procesu Y instrukci, že má vykonat činnost Z, na výsledek této činnosti proces X nemusí čekat, ale může se klidně pustit do činnosti A a o ukončení činnosti Z procesu Y je informován nepředvídatelně kdykoli v budoucnosti nezávisle na tom, co právě dělá proces X.

[Reklama]

[v]

nejdřív přesně definujte asynchronnost

Asynchronnost znamená, že proces X pošle procesu Y instrukci, že má vykonat činnost Z, na výsledek této činnosti proces X nemusí čekat, ale může se klidně pustit do činnosti A a o ukončení činnosti Z procesu Y je informován nepředvídatelně kdykoli v budoucnosti nezávisle na tom, co právě dělá proces X.

a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)

[Mirek Prýmek]

a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)

Řekl jste si o to: proces je zásobníkový automat se dvěma zásobníky a jedním mailboxem

[v]

a teď definujte proces (někdo by mohl argumentovat, že se zelenýma vláknama v rámci VM se nejedná o interakci mezi více procesy)

Řekl jste si o to: proces je zásobníkový automat se dvěma zásobníky a jedním mailboxem

tak teď by se mělo ukázat, že to nejde naprogramovat mimo kernel... ono to ale asi půjde, mi se to povedlo a to nejsem zrovna hvězdný programátor

[Mirek Prýmek]

tak teď by se mělo ukázat, že to nejde naprogramovat mimo kernel... ono to ale asi půjde, mi se to povedlo a to nejsem zrovna hvězdný programátor

S kernelem to nemá vůbec nic společnýho. VM je prostě VM - má vlastní virtuální čas (krokování). Jediné, čím ho může vnější svět (kernel) ovlivnit, je, že vzdálenost mezi dvěma kroky (instrukcemi) VM bude různě dlouhá v sekundách reálného času. To nás ale vůbec nezajímá, nemá to žádný vliv na to, co uvnitř VM jde nebo nejde udělat, je to metaúroveň.

[Reklama]

[v]

S kernelem to nemá vůbec nic společnýho.

zmínkou o kernelu jsem narážel na toto:

v user-space jen tak nenaprogramujete

[Mirek Prýmek]

zmínkou o kernelu jsem narážel na toto:

v user-space jen tak nenaprogramujete

Jo, to je (pro me) nepochopitelne michani zakladni urovne s metaurovni.

[Kolemjdoucí]

Pokud bude scheduler napsaný tak, že jednotlivá vlákna bude přepínat po vykonání jedné pseudoinstrukce (instrukce VM), tak to tak prostě bude dělat.

Pro kód interpretovaný VM-MPrymek jsem nucen souhlasit, jistě také lze mít za každou nativní instrukcí CALL Scheduler, na takové teoretické filozofování ale nemám čas ani náladu. V realitě většina praktických implementací VM to takto nemá a přepíná vlákna pouze při jisté dávce spolupráce s kódem vlákna.

Mezitím jsem si pročetl Erlang a preemptivní není ani Erlang Thread-switch je tam synchronní záležitost a může nastat pouze mezi jednotlivými redukcemi. Iluze preemptivnosti spočívá v tom že redukce se z povahy jazyka nedá napsat jako časově dlouhá věc. To co trvá dlouho, třeba komunikace s ODBC, se vystrčilo ven z erlang vlákna.

[Mirek Prýmek]

Mezitím jsem si pročetl Erlang a preemptivní není ani Erlang Thread-switch je tam synchronní záležitost a může nastat pouze mezi jednotlivými redukcemi. Iluze preemptivnosti spočívá v tom že redukce se z povahy jazyka nedá napsat jako časově dlouhá věc. To co trvá dlouho, třeba komunikace s ODBC, se vystrčilo ven z erlang vlákna.

Nejspis tady panuje nejake zasadni nedorozumeni. Cemu rikate "preemptivni" v kontextu kodu vykonavaneho ve VM a jak to souvisi s moznosti asynchronniho posilani zprav?

Samozrejme, ze veci, ktere sahaji mimo VM muzou kod uvnitr VM zaseknout, o tom se snad nemusime bavit, to je jasne, ne?! Proto se to taky "vystrci ven", aby to ty procesy uvnitr VM neblokovalo.

V realitě většina praktických implementací VM to takto nemá a přepíná vlákna pouze při jisté dávce spolupráce s kódem vlákna.

Opet, co presne tim myslite? Ze instrukcni sada toho VM obsahuje nejakou instrukci "SWITCH", ktera preda rizeni scheduleru? Takze kdyz vytvorim bytekod, ktery tu instrukci obsahovat nebude, tak se rizeni scheduleru nepreda? To snad takhle nemuzete myslet, jaky VM to takhle ma?!

[Pan Jan]

Cože? VM si to může zařídit jak chce, pokud jde o plánování. A je buřt jak to má OS, tím klidně může být i CP/M.

[Kolemjdoucí]

Cemu rikate "preemptivni" v kontextu kodu vykonavaneho ve VM a jak to souvisi s moznosti asynchronniho posilani zprav?

Preemptivní znamená že vlákno se přepne bez čekání na smluvenou činnost ve vlákně. Vykonat asynchronní událost na základě zprávy můžete jen v preemptivním prostředí. Specifikum Erlang jsem popsal.

Takze kdyz vytvorim bytekod, ktery tu instrukci obsahovat nebude, tak se rizeni scheduleru nepreda?

Bingo, pokud vlákno v kooperativním multitaskingu neprovede smluvenou činnost, tak má Scheduler smůlu. Nemusí to být pouze specifický bytecode, mohou to být i vhodné funkce, třeba počátek/konec redukce nebo funkce, alokace nové paměti, volání IO operace a jiné.

To snad takhle nemuzete myslet, jaky VM to takhle ma?!

Volání Scheduleru na základě smluvené činnost mají v Erlangu, pak tady:
http://wiki.squeak.org/squeak/382
The Squeak scheduler is cooperative between threads of the same priority

a tady:
https://downloads.haskell.org/~ghc/7.8.1/docs/html/users_guide/using-concurrent.html
A context switch will occur at the next heap block allocation after the timer expires (a heap block allocation occurs every 4k of allocation)

[Mirek Prýmek]

Vykonat asynchronní událost na základě zprávy můžete jen v preemptivním prostředí.

Porad nechapu, proc by to tak melo byt. Zpravu proste umistim do mailboxu adresata a odpoved si vyzvednu ze sveho mailboxu. Mezitim si delam co chci. Proc bych k tomu potreboval preemptivni multitasking, to prave nechapu.

Bingo, pokud vlákno v kooperativním multitaskingu neprovede smluvenou činnost, tak má Scheduler smůlu. Nemusí to být pouze specifický bytecode, mohou to být i vhodné funkce, třeba počátek/konec redukce nebo funkce, alokace nové paměti, volání IO operace a jiné.

No to je ale zasadni rozdil. Udelat nejakou explicitni cinnost, jejiz jediny vyznam a smysl je predat rizeni scheduleru je uplne neco jineho nez pravidlo, ze scheduler provede context switch jenom za nejake vhodne prilezitosti (konec funkce atd.)

To, ze ve vlakne dojde k ukonceni funkce prece neni "kooperace se schedulerem" a uz vubec to nema nic spolecneho s moznosti asynchronniho posilani zprav.

[Kolemjdoucí]

Zpravu proste umistim do mailboxu adresata a odpoved si vyzvednu ze sveho mailboxu. Mezitim si delam co chci.

A ta odpověď se do mailboxu dostala jak ? Vy jste ji tam nedal a protože jste si dělal svoje věci tak adresát se nedostal k CPU. Zřejmě ji tam dali Marťani :-)

No to je ale zasadni rozdil.

Zásadní rozdíl se zcela smaže, když pilný hlupák vrazí do funkce dlouhý výpočet.

[Mirek Prýmek]

A ta odpověď se do mailboxu dostala jak ? Vy jste ji tam nedal a protože jste si dělal svoje věci tak adresát se nedostal k CPU. Zřejmě ji tam dali Marťani :-)

Coze? Mailbox je proste fronta. Takze vlozim zpravu do fronty (=asynchronne "zavolam") a jdu si delat, co chci. Kdykoli me to napadne, tak v ramci toho "co chci" koukam do sveho mailboxu, jestli mi nahodou mezitim neprisla odpoved. To je asynchronni volani. A zadny "preemptivni VM" k tomu proste neni potreba.

Zásadní rozdíl se zcela smaže, když pilný hlupák vrazí do funkce dlouhý výpočet.

Zasadni rozdil je mezi tim, kdyz explicitne se schedulerem musim kooperovat a kdyz jsou jenom stanovena pravidla, kdy scheduler context switch dela (protoze je to tak treba efektivni, vyhodne, jedoduche atd.) - pravidla, o kterych kod vubec nemusi vedet a jsou mu uplne putna, protoze on z jeho pohledu bezi linearne bez preruseni (coz je definice multitaskingu).

------------------

Hele, uz me to hrani si na kocku a mys fakt nebavi. Porad nevim, co vlastne chcete dokazat, proc a jak, a uz me nebavi se na to ptat porad dokola. Tak nekdy priste nashle...

[Ondrej Nemecek]

Já teda nevím, ale není to prostě tak, že Mirek Prýmek se na to dívá z pohledu VM a Kolemjdoucí z pohledu OS případně železa? Mi to tak přijde.

V jednom OS vlákně můžu mít asynchronní akce, nebo ne? Prostě se střídají a nepotřebuju na to ani víc OS procesů ani víc OS vláken. Tak to má třeba javascript.

Nebo mě opravte, jestli jsem mimo.