Tajemství automatické likvidace - druhá část
V první části jsme se dozvěděli, jaké bylo prostředí, jaké byly podmínky a co mělo být efektem řešení. Nyní si povíme, jak se nám to povedlo. První, co je nutno udělat, je potřeba odstoupit od běžného sekvenčního myšlení a hledat něco jiného. Co takhle pokusit se namodelovat chování toho "města". V modelu ale musejí jet auta ve všech ulicích současně. To vyžaduje přejít od sekvenčního programu k paralelnímu zpracování a spolupráci procesů. Aby paralelní zpracování mělo smysl (a také dosahovalo uspokojivých výkonů), musíte najít bod nebo body, kdy, abyste nečekali na dokončení vnější operace, jdete zatím počítat něco užitečnějšího. Tento bod, protože do výpočtu nezasahuje interaktivně člověk, je celkem jasný. Jedná se o čtení respektive zápis dat do např. databáze. Tehdy samozřejmě databáze ve smyslu dnešních, které jsou vybaveny softwarem, který vám řeší problematiku přístupu k informaci, neexistovaly. Bylo nutno navrhnout a napsat vše.
Binární vyhledávání
Od návrhu struktury záznamů, přes návrh indexů pro přístup až po binární hledání záznamu. A to vše ještě s ohledem k tvaru a možnostem skutečného fyzického záznamu na nosiči. Pro ty, co nevědí o co se jedná, vysvětlím. Ostatní mohou přeskočit na další odstavec. Binární hledání, někdy též nazývané metodou půlení intervalu, se dá připodobnit k hledání slovíčka ve slovníku. Otevřete slovník v polovině a podíváte se, zdali tam hledané slovíčko je. Pokud není, tak se rozhodnete, zda podle abecedy leží před a nebo za danou stránkou. Potom opět jdeme do poloviny intervalu, kde by mohlo ještě být (podle toho jak jsme se rozhodli). V případě náhodně vyhledávaných dat je to zcela určitě nejrychlejší metoda.
Řízení procesů
Další co bylo potřeba vyřešit, bylo napsat program (Monitor), který by řídil jednotlivé procesy, které v modulu běžely. Jednalo se vlastně o jakousi interní „operační“ exekutivu. Ta vlastně jenom spouštěla jednotlivé procesy podle toho, zda již byly na řadě a v případě, že čekaly na dokončení I/O operace, zda již byla dokončena. Pak tam byl proces načítání dat (tj. vlastní účetní položky), zápis zpracovaných položek a zápis zatím nevyřešených položek. Proces inicializace zpracování by se dnes označil jako centrální konstruktor použitých objektů. V neposlední řadě vlastní „likvidace“.
Kód tohoto procesu, což vlastně by v dnešní době byla aplikační funkce objektu likvidace s názvem „likviduj“, byl napsán reentrantím způsobem. To znamená, že byl psán tak, aby se v něm nevyskytly žádná dočasně uložená data, která by mohla být při použití tohoto kódu jiným procesem, omylem přiřazena nesprávnému procesu. Všechny potřebné hodnoty vlastního procesu byly uloženy přes pointer do autonomní oblasti daného procesu. Tím pádem byl kód programu současně přístupný více procesům najednou a mohl v paměti existovat pouze jednou pro více současně běžících procesů. Dnes by se řeklo, že veškerá data procesu byla jako referenční typy uložena v autonomní oblasti daného procesu.
Vše bylo napsáno sice v assembleru, ale jednalo se o makro assembler a pro sálový stroj, takže úroveň možností byla podstatně dál než u assembleru dnešních PC. Podívám li se na problém dnešním pohledem objektového programování, tak procesy „likvidace“ (kterých bylo celkem 10), byly jako instance třídy likvidace vygenerovány v hlavním (řídícím) programu (Monitor). Vlastní ale funkčnost (aplikační procedura „likviduj“) byla pro třídu likvidace společná v modulu likvidace. Celé řešení si lze představit jako deset účetních, kteří sedí vedle sebe, účtují a hned si předávají výsledky.
Hlavní program měl kromě řízení procesů ještě dohlížet na spouštění tzv. iteračních kol. Ty vznikaly tím, že pokud vám přišel nějaký kredit, bylo nutno se podívat, zda se nedá zaplatit něco dál. Pokud ano, bylo spuštěno další kolo. Limit byl deset kol, ale nikdy jsme jej nedosáhli. Účinnost byla ale tak veliká, že jsme vždy skončili dřív.
Výsledky
Zajímavé bylo, že program při opakování na stejná vstupní data (jednalo se o dávkový program), nedával stejné výsledky. To bylo způsobeno tím, že náš počítač ve srovnání s dnešním PC byl pomalu lezoucí šnek s minimální pamětí (cca 300 000 instrukcí/s a 1 Mb vnitřní paměti). A tak jsme museli hledat takové postupy, abychom z něj vytěžili co nejvíce. Statistika zpracovávaných údajů říkala, že 60-70% platebních transakcí je v rámci okresu tj. jedné pobočky. Tak jsme přemýšleli jestli toto nelze nějak využít. Náš „sálový“ počítač totiž uměl současně pracovat tj. číst a zapisovat data na třech nezávislých sadách disků. A tak nás napadlo, že kdybychom při vytváření (dnes by se řeklo databáze) zapisovali data tak, že po naplnění celé jedné plochy na disku bychom další data zapisovali na další fyzický disk, pak na třetí a zase znova na první, tak bychom získali databázi na třech fyzických nosičích. Pokud bychom je pak dali každý na jiný kanál, tak bychom mohli v 60% případů současně číst a zapisovat data na třech discích najednou. Tak jsme tento nápad realizovali. Našich deset procesů - likvidátorů, četlo současně data ze třech nezávislých disků.
Díky tomu ale začalo záležet na tom, jak v okamžiku startu byly vůči sobě natočeny tyto disky a jakou vzájemnou rychlostí se točily. Podle toho, jak se dotáčely na začátky stop, docházelo ke čtení a rozbíhaní se likvidace jednotlivých procesů. Ty potom přinášely jinak kredit a vše pak probíhalo podle aktuálního stavu již zpracovaných dat, který nebyl při opakování prakticky nikdy stejný. Celé to mělo charakter, jako když se zeptáte na nejrychlejší cestu na letiště a dostane odpověď podle stavu v daném okamžiku. Pokaždé je odpověď poněkud jiná, ale velmi se podobají. Protože při opětovném spuštění se vám prakticky nemohlo podařit nastavit absolutně shodné počáteční podmínky a ani zaručit shodný průběh výkonu, tak logicky docházelo k "různým" výsledkům.
Na uvedeném příkladu je vidět, že při řešení nějaké problematiky je nejdůležitější si ujasnit, co se vlastně chce a proč. Teprve potom máte možnost vyhledat odpovídající řešení. Nerozumná maximalizace požadavků respektive funkčnosti od zadavatele, může nakonec celý záměr zhatit. Představte si, že se snažíte odhadnout čísla ve Sportce. Nač požadovat program, který je schopen určit co padne za čísla, když bohatě stačí, kdyby v 50% případů jich určil správně jenom 80%.
