Názor k článku Linspire a Microsoft: Další dva kamarádi od I/O - Stále nechápu. Proti destrukci způsobené přetečením zásobníku mě...

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 6. 2007 10:10

    I/O (neregistrovaný)
    Stále nechápu. Proti destrukci způsobené přetečením zásobníku mě ochrání MMU. Pokud k něčemu takovému dochází, je to jiná hrubá chyba a nic jiného než odstřel procesu na základě generované výjimky nemá smysl provádět. To už známe 40 let. Ladit takové situace už umíme ještě déle.

    Aha, takže ve skutečnosti myslíte reentrantní kernel? Kde jinde než v rámci kódu jádra se podle vás provádí přepnutí kontextu? To máte nějaké popletené... Hlavně tedy nechápu, proč by se to mělo nazývat preemptivní kernel, z terminologického hlediska je to nesmysl. Jádro může být reentrantní nebo nemusí. Pokud podporuje multitasking, v podstatě jakoukoli formu, pak musí být reentrantní vždycky, to je základní předpoklad celé filosofie multitaskingu. V případě preemptivního multitaskingu je jen otázkou, zda přechodem na kód jádra má dojít k zákazu přepnutí kontextu z popudu časovače, či ne. Jednoduchá odpověď neexistuje. Zajistíme-li, že operace nevedoucí k přepnutí kontextu proběhnou rychle - a o to by mělo jít vždy - pak tento zákaz přepnutí v rámci sdílení času nevadí. Pokud naopak přepnutí povolíme, znamená to, že dodatečně musíme ošetřit kritické sekce nad strukturami jádra, což zpětně vede ke zpomalení služeb jádra. Rozhodně v žádném případě není pravda, že by to mělo vždy za následek zvýšení průchodnosti jádra!!! Naopak tímto mechanismem můžeme neúměrně zvýšit režii systému způsobenou zbytečným přepínáním kontextu, což je časově poměrně náročná operace.

    Pokud jde o ten FS, jestli jsem to dobře pochopil, tak jde teda jen o převzetí způsobu práce s databází na úroveň FS. To už se zkoušelo někdy v 70. letech nebo na konci 60. let, ale zavrhlo se to a byly k tomu dobré důvody, proč to tak nedělat.