multithreading azt jelenti, hogy EGY PROCESSZEN belül az oprendszer megengedi, hogy több szálon futtassunk dolgokat... Ezek a threadek márpedig MEGOSZTJÁK az address space-t. Ezt írja a két link, amit bepészteltél.
az, hogy ez hogy van megimplementálva, kernelben-e vagy userspace-ben, hogy egy IO-ra vagy condition variable-re váró threadet signalokkal ébreszt-e fel a kernel vagy füstjelekkel, a schedulingre timer interrupt-ot vagy varázslatot használ-e, az már implementáció kérdése és a futó programot nem érdekli és ne is érdekelje.
Szerintem nem teljesen érted a dolgot. Thread azóta létezik, hogy programflow van, és program counter van a számítógépben, és halad előre a végrehajtás. Vegyél egy C64-et alapul. Ha semmilyen megszakítás nem fut, mert letiltasz mindent, akkor is van egy thread-ed, a főprogramod fut benne!
a te user módú "programodban" sosem fog lefutni egy megszakítás... az mindig kernelben fut le, kernel módban és kernel stackkel... s annak akkor is le kell futnia, amikor az a cpu pont egy kernel threaden dolgozik. És ez a megszakítás nem a te programod érdekében végez dolgokat, hanem a rendszer érdekében, elsősorban. persze, a kernel ad mechanizmusokat, hogy a te programod is valamelyest szinkronizálhasson egy ilyen eventtel...
A "user mód", meg "kernel mód" egy operációs rendszer függő dolog, a thread fogalma meg általános. Ahogy azt írtam korábban.
ezt nem értem. mi az, hogy "interrupt hatására induló, futó szál"? te el is olvastad, amit kérdeztél? ez az angol mondat egész pontosan azt mondja, hogy a threadek megosztják az address space-t: a kódot és az adatokat... WITHIN THE PROCESS (amit levágtál a mondat végéről).
De a te programod SOSEM fogja elérni a kernel adatait (ahol a megszakítás fut) és az interrupt handlerből sem nagyon lehet matatni az éppen futó user módú taszk memóriájában (mert lehet, hogy az a page pont ki van swappelve... linuxon van copy_from_user(), de azt nem lehet ISR-ből használni, hanem ehhez kell kérni egy tasklet, workqueue, bottom-half, stb. és majd abban).
Kevered az absztrakciós szinteket. Nincs kernel, felejtsd el. Még egyszer leírom: a thread egy logikai koncepció, ami megmondja, hogy hogyan halad előre a program végrehajtása.
Gondolom láttál már igazi, kicsit nagyobb programot, amiben nem csak egy iskolai példája van az interruptnak. Ha van egy interruptod, az nem csak ott lóg a levegőben, és önmagában csinál dolgokat, hanem általában adatokat kell feldolgoznia. Vegyünk egy hőmérőt. Ha mérés van, akkor például triggerel egy interruptot, és ki lehet olvasni az adatokkat a hőmérőből a triggerelt interrupt kódjában. Adatmegosztás: Szerinted ha ez az interrupt nem tudna adatokat megosztani mással, akkor hogy oldaná meg, hogy például a programban máshol felhasználd a hőmérsékletet? Programkód megosztás: Szerinted az interrupt nem hívhat meg olyan programkódot, amit más is hív? Az interrupt egy másik szál? Nyilvánvaló, az eredeti szál megszakadt, és az interrupt kezdett el futni, ami egy teljesen másik programkód, mint ami futott éppen (aminek a végrehajtása megállt).
ezt nem értem. mi az, hogy "interrupt hatására induló, futó szál"? te el is olvastad, amit kérdeztél? ez az angol mondat egész pontosan azt mondja, hogy a threadek megosztják az address space-t: a kódot és az adatokat... WITHIN THE PROCESS (amit levágtál a mondat végéről). De a te programod SOSEM fogja elérni a kernel adatait (ahol a megszakítás fut) és az interrupt handlerből sem nagyon lehet matatni az éppen futó user módú taszk memóriájában (mert lehet, hogy az a page pont ki van swappelve... linuxon van copy_from_user(), de azt nem lehet ISR-ből használni, hanem ehhez kell kérni egy tasklet, workqueue, bottom-half, stb. és majd abban).
A válaszod alapján azért nem érted, mert hasonlóan tekinthetsz a kérdésre, mint amikor valaki azt mondja, hogy "az internet az a Google". Nem értesz szerintem egy mélyebb fogalmat, ami a "thread", ami egy program logikai végrehajtási szála, és összekevered egy adott implementációval, mint például a "kernel thread". Különböző szinteken beszélünk ugyanarról a fogalomról. Bzt a "thread"-et említette, ami pontosan ezt jelenti, amit én leírtam.
Ez szerintem olyan, amiket írsz, mint amikor valaki a paprikás krumpli főzéséről beszél, de nem ismeri a hő fogalmát. Az előbbi egy konkrét tevékenység, amihez kell a hő, a hő pedig egy alapvető pedig egy alapvető fizikai jelenség, amely nélkül a főzés fogalma értelmezhetetlen.
Korábban írtam: "Persze én elhiszem, hogy ha valaki "thread"-et említ, akkor leginkább az OS thread-re gondolnak először (ma)." - Ezt válaszoltad: "nem értem, mit akarsz ezzel mondani."
Azért mert pontosan ezt teszed, amit én írtam. Teljes egészében csak a kernel által kezelt, és OS által indított thread-ben gondolkozol, nem pedig az általános fogalomban, hogy mit jelent egy thread. Meg tudnád azt fogalmazni ezek után, hogy neked mit jelent egy thread, miért ezt a nevet kaphatta? Szerinted mi a definiciója?
szerintem meg ti filozófálgattok az interruptokról és a signalokról, amikor multithreadingről beszélünk... bzt szerint az a "multithreadingnek" egy formája... lol (én erre kértem forrást)
Továbbra sem gondolom filozofálgatásnak, egyrészt én kizárólag csak a thread fogalmáról beszéltem, ami bele tartozik az is, amit Bzt írt (hogy külön threadnek tekinthető, ha egy különálló programkód futás indul el egy interrupt hatására (az interrupt kódja), remélem ez így már érthető), másrészt, ha egy alapfogalom érhető, akkor nem kell rá példákat keresni, meg külön megemlíteni forrásokban, csak értelmezni kell az alapfogalmat. A gravitáció például: nem szükséges egy tanulmányt belinkelnem neked arra, hogy ha egy almát elengedek a föld felett, az le fog esni. Gondolom elhiszed, ha érted, hogy mi az a gravitáció.
Amikor egy programról beszélünk, fontos, hogy nem csupán konkrét implementációról van szó, hanem olyan elgondolásokról és absztrakciókról is, amelyek a program működését irányítják.
Bízom benne, hogy így már sikerült tisztázni, hogy hol beszélünk másról, és most már érthetőbb, hogy ki mire gondol.