Já mám stále pocit, že mluvíte cizím jazykem.
Co myslíte tím, že oddělení procesů stojí dost prostředků? Uveďte prosím nějaký příklad, asi oba myslíme něco jiného, protože nechápu co na tom co myslím já by mohlo stát mnoho prostředků.
Přepnutí kontextu je jedna z časově nejnáročnějších operací, která na systémech s ochranou paměti prakticky odsoudila mikrojádra mimo hru, souhlasím a řekl bych, že oba myslíme to samé. Co myslíte pod pojmem "kernel mode transition", že je to podle vás zase tak drahé? S rozlitým mlékem souhlasím, sám jsem to řekl hned v první reakci. Pokud jazyk něco neumožní, znamená to předpoklad, že ten jazyk je používán blbem nebo nezkušeným člověkem, který neví co dělá - př. Pascal. Problémů, které tím způsobíme, je ale víc, než těch, kterým jsme zabránili. Uzavřeme si cestu k přímočarým efektivním řešením, budeme muset okecávat jednoduchou věc tak, abychom nepoužili přímočaré, ale potenciálně nebezpečné řešení. Tudy rozhodně cesta nevede, je to příliš defenzivní způsob programování který přímo implikuje neefektivní řešení problémů. Zabránění deadlocků se zkoumalo celá desetiletí a bylo to dávno uspokojivě vyřešeno. Pokud neprogramuje prase, řešení je snadné, stejně jako dynamická detekce deadlocku když už k němu dojde. Staticky objevit deadlock je věc neřešitelná a matematicky je toto tvrzení dávno dokázané, viz přednášky z OS (nebo už se to dnes neučí?).
"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" - co myslíte větou "za běhu kódu můžeme utrhnout execution a provést context switch"? To snad ani nemá hlavu a patu, nebo opět myslíme oba něco jiného. Znovu opakuji, že k přepnutí kontextu jindy, než v okamžiku, kdy se vlákno (proces) nachází v režimu jádra, dojít nemůže. Už z principu - trošku si ty přechody stavů představujte. A pokud povolím časovači, aby přehodil kontext ve chvíli, kdy se proces v režimu jádra schyluje k uspání sama sebe a přepnutí kontextu, pak tím na průchodnosti systému rozhodně nepřidám. Znovu opakuji, že to není tak jednoduché, jak to tu presentujete. SMP bych sem vůbec netahal, s tím jsou spojeny jiné problémy a reentrance leží mnohem níže. U SMP je problém potřeba provádět některé typy operací jednou instrukcí, ale to zas tak příliš nesouvisí s reentrancí jako takovou. Reentrance je nezbytná pro multitasking vůbec. Bez reentrance není multitasking a bavit se o SMP už pak vůbec nemá smysl. Takže opět nějak nevím, co myslíte větou "Pokud není reentrantní, je to problém při SMP (scalability velmi trpí)". Opět se mi zdá, že věta nemá hlavu ani patu, nebo že se bavíme o různých věcech.
"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" - jádro bez statických dat si představit nedokážu. Reentrantnost ještě neznamená, že je nutno použít nějakou formu IPC. To je spojeno až s tím, co nazýváte preempce, ale ani tehdy to není nezbytně nutné - záleží na situaci a na řešení. Často je průchodnější kritickou sekci řešit prostě zákazem přepnutí kontextu - pokud se jedná o časově zanedbatelnou trivialitu typu změna údaje v tabulce procesů. Postavit nad tím semafor by bylo méně efektivní. V každém případě dopsat ochranu před kritická data není zas takový problém oproti situaci, kdy to tam je od začátku. Velice často se to tak dělá - jádro se odladí se zákazem přepínání a pak se postupně povoluje přerušení v dalších a dalších místech. Není to rozhodně nic, co zavání nějakými kritickými problémy. Dá se předpokládat, že i NT se takovým způsobem ladily. Odkud plyne váš přepoklad, že to nutně zavání mizerným výkonem, je pro mne neznámá. Používání statických dat na výkon systému negativní vliv mít nebude. Náhradou za lokální data se problém může ještě prohloubit.
Ty transakce jsou mi už jasné... jistě se najde řada aplikací, kde to má nějaký smysl, ale otázkou je jestli jich je tolik, aby se to muselo implementovat na úroveň FS.
Názor k článku
Linspire a Microsoft: Další dva kamarádi
