Pripajam sa ... je to super. Az skonci seria, autor by mal vydat o tom knizku.
User threads su obdobnym sposbom implementovane v JRE (java runtime environment) - cela tato "habadura" sa tam vola "green threads", pricom nevyzaduje nejaku spec. upravu jadra. JRE je mozne explicitne prepnut do tohoto rezimu. Takze aj spustanim JRE v tomto mode mame moznost si lahko preskusat rozdiely medzi strategiou "uzivatelkeho" prepinania threadov a prepinania threadov jadrom. Prepinanie threadov je riesene upravou systemovych volani ( io, sleep, ... ), ale problem so zahltenim aplikacie v pripade nekonecneho cyklu bez io opracie je aktualny stale.
Jenym z hlavnych argumentov vsak je to ze "dobre napisana" a odladena aplikacia dokaze v pripade green threads lepsie a "hladsie" vytazit procesor, pretoze minimalizuje cas jadra kedze nedochadza k tak castemu prepinaniu kontextu (jadrom). Vypoctovy vykon (?!?!) aplikacie ziska o par % navrch oproti tej istej aplikacii s preemptivnym prepinanim threads.
Podle mne ten článek je dobře čtivý do okamžiku, než se začnou rozebírat stavy procesů. Tam se náhle ocitnou pojmy jako "syscall", "userspace", které čtenář musí znát odjinud než z článku, zřejmě se musí zabývat programováním Linuxu na poměrně nízké systémové úrovni, aby věděl o co jde.
Jako přehled-srovnání, pro někoho, kdo aspoň jeden z popisovaných systémů zná velmi dobře, to je možná dobře napsáno, ale ostatní čtenáři nevím, nevím.
Chápu, že úvod do všech odborných pojmů, jen jednorázově použitých, by mohl být příliš dlouhý a článek neúnosně nabobtnat. Pak by měl článek obsahovat odkazy na to, kde se s těmito pojmy lze podrobně seznámit, anebo být veden ve vyšší úrovni abstrakce, aby bylo možné čtenáři vysvětlit rozdíly implementace mezi uvedenými systémy, ale nebylo nutné jej zatěžovat detailními pojmy, jež nezná.
Srovnám-li např. tento článek s nedávnou sérii "Stavíme mailový server", pak je podle mě psán tento zmíněný seriál s mnohem větší péčí a ohledem na čtenáře. Čtenář si s ním vystačí jako se samostatnou informací. Tento článek o schedulerech mi naopak přijde jako rychlíkové výňatky z nějakého většího textu. Autor podrobný kontext asi zná, ale běžný čtenář spíše ne a zajímá-li ho téma skutečně, bude po něm muset únavně pátrat.
Tož jsem si Černého Petra kritiky dnes vyzvedl já, možná že jsem netypický čtenář root.cz, možná že jsem.
Nebudte smutny, bezny ctenar si porad muze koupit
MF DNES nebo proste cist jen neco. Naopak, bylo by chybou travit cas ctenim neceho, co Vam k nicemu neni.
Bezny ctenar teto serie to bud zna odjinud nebo vygoogluje, toho neni treba se bat.
Seznam pouzitych terminu by byl jiste nutny u ucebnice, ale u zabavneho platku pro velmi uzce profilovanou IT sektu unixovych nadsencu to neni moc potreba.
Pro člověka neznalého pojmu auto bude stejně tak nesrozumitelný popis dopravní nehody a domnívám se, že pár tisíc lidí na světě slovo auto nezná. Bez znalosti základních pojmů nelze číst žádný text.
Presne tak, urcita minimalni znalost pojmu je nutna pro cteni _JAKEHOKOLI_ clanku.
To je jako kdyby jste se divil, ze k novinovemu clanku o fotbalovem utkani neprikladaji pravidla (kdyby traba nekdo nevedel co je to polocas :-)
Poločas je těch prvních dvacet minut hokejového utkání, ne?
Zdravim,
nerozumim tomu, jak muze byt O(1) scheduler opravdu O(1). Jestlize se sleep_avg zvetsuje o 1 kazdy tik, kdy proces spi, tak se prece musi kazdy tik projit vsechny procesy a sleep_avg jim zvysit, ne?
A co takhle mit u procesu tik posledniho probuzeni a sleev_avg pocitat jako rozdil aktualni a ulozene hodnoty? (Ne ze bych vedel, ze se to tak dela, jen mne to napadlo.)