Názor k článku HelenOS nikdy nebude dokončený, říká jeho autor Jakub Jermář od M.D. - Netrpi mikrokernel vykonove oproti monolitickemu jadru? Ano, komunikační overhead...

Netrpi mikrokernel vykonove oproti monolitickemu jadru?

Ano, komunikační overhead IPC bude vždy v principu o něco větší než běžné volání funkce. Většina vývoje kolem mikrojader v 80. a 90. letech se právě točila kolem toho zoptimalizovat tento overhead co nejvíce.

Myslím si ovšem, že v dnešní době už ten fyzický overhead nehraje takovou roli. Koupit si o 10 % rychlejší procesor kvůli overheadu mikdrojádrové architektury je triviální a je to rozumná investice, protože za odměnu můžeme získat modulární, snadno udržovatelný a bezpečný kód. Údržba složitého monolitického softwaru, kde drobná chybka v málo podstatném modulu může způsobit pád celého systému, se jeví jako mnohem dražší a dlouhodobá investice.

musi dochazet mnohonasobne vicekrat ke "context switch"

Tohle je tak trochu nepochopení. V dobře navrženém mikrojádrovém systému dochází (za předpokladu asynchronní komunikace) ke zhruba stejnému počtu přepnutí kontextu jako v monolitickém systému — především z důvodu preempce nebo blokování.

Mikrojádrové systémy se zkrátka nesmí programovat tak, že se vezme "monolitický" sekvenční kód s funkčními voláními a ten se mechanicky převede na synchronní zasílání zpráv. Když se vhodně využije asynchronicita komunikace, koncepty jako future a promise a rozumný způsob předávání dat, tak se převážná část overheadu redukuje na nutné minimum.

jedna komponenta "zblazni" dokaze saturovat cely system jen rezii zprav

Počet zpráv, které může mít jedna komponenta v jeden okamžik "ve vzduchu", je omezen. Další zprávy si frontuje ve vlastní režii a tudíž ne více času, než je naplánována plánovačem. Takže jedna komponenta nikdy nezasaturuje celý systém.

Jistě se může stát, že nějaký proces bude soustavně "vyžírat" veškery procesorový čas, který mu plánovač dá, ale to se pochopitelně může stát i v monolitickém systému.

ji je treba napr. restartovat

Jak jsem už psal někde výše, restart podle mě nic neřeší :)

Jak se vlastne takovy system debuguje pri programovani, myslim tim kdyz se vse odehrava dost asynchrone?

Souhlasím, že debuggování asynchronní komunikace je složitější než debuggování sekvenčního kódu. Je potřeba sledovat komunikaci a všechny komunikující strany. V principu to dost připomíná ladění síťové komunikace ..

Na druhou stranu, v dohledné době budou mít procesory asi jen víc a víc jader a hardwarových vláken, takže luxusu přehledného sekvenčního kódu si stejně asi moc neužijeme :)