En is pontositanek egy par aprosagot:
Multithreading: [...] Ha ennek a regiszternek az értéke elmentődik a memóriába, és egy, a normál programfolyamtól eltérő érték kerül helyette bele, akkor többszálú programvégrehajtásról beszélünk.
Ez itt nem teljesen pontos. Amit irsz, hogy _csak_ az IP/PC regisztert mented memoriaba, az a klasszikus megszakitas-hivas, nem pedig a multithreading. Multithreading eseten is mentened kell a processzor belso allapotat, es az adott thread folytatashoz azt vissza kell allitanod 1:1-ben. A konnyites tenyleg annyi, ahogy mondod, hogy a cimter az valoban nem fog valtozni, igy a "teljes allapot" mentese egy-ket fokkal egyszerubb, viszont sokkal hatekonyabb (hiszen par tucat regiszter mentese meg visszaallitasa sokkal gyorsabb mint egy cimter-valtas es/vagy TLB cache flush utani feleledes). De ebben az allapotban (avagy context-ben) benne van nemcsak a IP/PC meg az osszes "egyszeru" regiszter, hanem meg a flag-ek is meg a SIMD, FPU, stb, regiszterek is. Szoval egy modern procinak a context az mar egy egesz nagy valami is lehet. Ha csak a register file-t nezzuk mar ugy is.
Ha megnezed a `man 2 clone` leirast, akkor abbol azt lehet latni hogy a "multithreading" es a "multiprocesszing" kozotti atmenet az egeszen folytonos, es uj processzek/threadek letrehozasakor valojaban temagad tudod hangolni hogy mennyire is kezdjen el kulonbozni a ket processz, marami a cimteret (meg a tobbi I/O eroforrast) illeti. Lehet minden teljesen kozos, sot, szelsoseges esetben a stack is lehet kozos. Oke, ezutobbi elegge extrem, nem tudom hogy ki az aki annyira bator es/vagy mi arra az use case ha kozos a stack :) (hiszen akkor mar egy fuggvenyhivast sem tudsz csak ugy vegrehajtani). De pont a stack kulonbozosege implikalja hogy minimalis kulonbnsegek mar thread-ek eseten is megjelenhetnek (gondolj bele hogy pl a kernel "alalapozhat" meg memoriat az egyik thread stack-jenek, ha az tulsagosan elkezdene noni lefele, mig a masiknak nem kell). Persze ettol meg a context switch olcso marad, marad(hat) ugyanaz a cimter, jo ez.
A szinkron/aszinkron I/O-val kapcsolatban pedig:
- ezelobbi esetben a processz/thread egyszercsak ugye eljut oda hogy kell neki adat: akkor meghivja a megfelelo rendszerhivast, es az vagy blokkol (blocking I/O), vagy nem (nonblocking), vagy meg tudod nezni hogy tobb forrasbol szarmazo adatok eseten melyikben van valami (azaz melyik blokkolna ha blocking modon hivnad). Ezutobbi az amit a select() es baratai csinalnak, es ezert hivjak ezt "szinkron multiplexing"-nek. Ez mind-mind szinkron.
- Az aszinkron I/O eseten meg beallit(hat)od hogy egy adott forras (pl file descriptor) eseten, ha az nem blokkolna egy blocking muvelet soran, akkor hivjon meg a kernel egy, az adott processzhez tartozo signal handlert (ld: SIGIO). Lenyegeben olyan mint egy interrupt, csak a kernel "csinalja" es nem-privilegizalt modon is fut (de privilegizalt folyamatok kozbenjarasaval).
Programozasi szempontbol a multithreading meg aszinkron I/O azert erdekes mert ugyanabban a cimterben szakad meg ezert vagy azert (preemption vagy interruption) a program futasa es kerul at egy masik pontra. Igy mindket entitas (ket kulonbozo thread, vagy egy processz/thread es signal handler) eseten nagyon figyelned kell hogy a kozos cimterben levo valtozok kozul mi az ami volatile es mi az ami nem. Ez akkor is igaz ha ket kulonbozo processzed van, latszolag kulonbozo cimterrel, de van egy kozos hasznalato shared memory terulet is es abba pakolgat az ember valtozokat. De persze a ket fenti, "klasszikus szinkron" meg "klasszikus aszinkron" esetek kozott sem annyira eles az atmenet. Peldaul csinalhatsz olyat hogy: a/ egy "A" thread letrehoz egy "B" thread-et, ami csak loop-olva varja hogy valahonnan, egy adott file descriptorrol jojjon adat, es ha jon akkor atir megfelelo modon egy, a kozos cimterben levo volatile valtozot. Vagy b/ ez az "A" thread csinal egy SIGIO handlert, amit majd meghiv a kernel ha tortenik valami akcio egy adott file descriptoron. A handler pedig ekkor atir megfelelo modon egy, a kozos cimterben levo volatile valtozot. Az "A" thread szemszogebol nezve az a/ es b/ esetben ugyanaz tortenik, az a processz nem tudja megkulonboztetni a ket implementaciot. Mindketto hatekony lesz, de hogy melyik lesz hatekonyabb az mar implementacio/kernel/finomhangolas/stb fuggvenye.