Oddělení procesů stojí celkem dost prostředků. Takový context switch není zdaleka zdarma, a kernel mode transition je ještě dražší. Popisoval jsem tu v jiném příspěvku alternativní způsob oddělení procesů (SIP), a dával tam linky. Podstata je ale v tom, že řešit nastalý problém je v podstatě k ničemu, protože mléko je už rozlité. Pokud například jazyk neumožní pointerovou aritmetiku (a pointery na funkce zapouzdří tak, aby s nimi nešlo manipulovat), odstraní se příčina řady chyb. Viz též co jsem psal o statické analýze kódu (například záruka typu "kód oneobsahuje deadlock").
Ano, preemptivní (za běhu kódu můžeme utrhnout execution a provést context switch) a reentrantní (kód lze provádět na více místech najednou) kernel. Mluvím o přepnutí kontextu ve chvíli, kdy se thread (proces) nachází v režimu jádra. Samozřejmě pokud kernel není preemptivní, zvyšuje se lacency. Pokud není reentrantní, je to problém při SMP (scalability velmi trpí). Samozřejmě preemptivní a reentrantní kernel nesmí držet statická data, a kde je to nutné (jako že takových míst je dost), musí se použít nějaký mutex. Když se tak postupuje od návrhu, je to celkem v pohodě. Pokud se preempce kernelu implementuje dodatečně, zavání to hromadou bugů (viz Linux kernel s CONFIG_PREEMPT), a mizerným výkonem (opět viz Linux; nevyznám se v Linx kernelu, ale zřejmě by to chtělo snížit míru používání statických dat, což se dodatečně bude dělat velmi špatně).
ACID FS nesouvisí s DB. DB jsem použil pouze pro demonstraci možností. Jiným použitím je, když zahájím transakci, na webový server budu pět minut kopírovat novou verzi aplikace, a pak dám comit. Nejprve budou všecny soubory ve staré verzi, a po commitu v nové verzi. Možností použití transakcí je celá řada.
Názor k článku
Linspire a Microsoft: Další dva kamarádi
