Tajomstvo automatické likvidácia - druhá časť
V prvej časti sme sa dozvedeli, aké bolo prostredie, aké boli podmienky a čo malo byť efektom riešenie. Teraz si povieme, ako sa nám to podarilo. Prvé, čo treba urobiť, je potreba odstúpiť od bežného sekvenčného myslenia a hľadať niečo iné. Čo takto pokúsiť sa namodelovať správanie toho "mesta". V modeli ale musia ísť autá vo všetkých uliciach súčasne. To si vyžaduje prejsť od sekvenčného programu k paralelnému spracovaniu a spoluprácu procesov. Aby paralelné spracovanie malo zmysel (a tiež dosahovalo uspokojivých výkonov), musíte nájsť bod alebo body, kedy, aby ste nečakali na dokončenie vonkajšie operácie, idete zatiaľ počítať niečo užitočnejšie. Tento bod, pretože do výpočtu nezasahuje interaktívne človek, je celkom jasný. Jedná sa o čítanie respektíve zápis dát do napr. Databázy. Vtedy samozrejme databázy v zmysle dnešných, ktoré sú vybavené softvérom, ktorý vám rieši problematiku prístupu k informácii, neexistovali. Bolo nutné navrhnúť a napísať všetko.
Binárne vyhľadávanie
Od návrhu štruktúry záznamov, cez návrh indexov pre prístup až po binárne hľadania záznamu. A to všetko ešte vzhľadom k tvaru a možnostiam skutočného fyzického záznamu na nosiči. Pre tých, čo nevedia o čo sa jedná, vysvetlím. Ostatní môžu preskočiť na ďalší odsek. Binárne hľadanie, niekedy nazývané tiež metódou polenie intervalu, sa dá prirovnať k hľadaniu slovíčka v slovníku. Otvorte slovník v polovici a pozriete sa, či tam hľadané slovíčko je. Ak nie je, tak sa rozhodnete, či podľa abecedy leží pred a alebo za touto stránkou. Potom opäť ideme do polovice intervalu, kde by mohlo ešte byť (podľa toho ako sme sa rozhodli). V prípade náhodne vyhľadávaných dát je to celkom určite najrýchlejší metóda.
Riadenie procesov
Ďalšie čo bolo treba vyriešiť, bolo napísať program (Monitor), ktorý by riadil jednotlivé procesy, ktoré v module bežali. Jednalo sa vlastne o akúsi internú "operačný" exekutívu. Tá vlastne len spúšťala jednotlivé procesy podľa toho, či už boli na rade a v prípade, že čakali na dokončenie I / O operácie, či už bola dokončená. Potom tam bol proces načítanie dát (tj. Vlastné účtovné položky), zápis spracovaných položiek a zápis zatiaľ nevyriešených položiek. Proces inicializácia spracovanie by sa dnes označil ako centrálny konštruktor použitých objektov. V neposlednom rade vlastné "likvidácia".
Kód tohto procesu, čo vlastne by v dnešnej dobe bola aplikačné funkcie objektu likvidácia s názvom "likviduj", bol napísaný reentrantím spôsobom. To znamená, že bol písaný tak, aby sa v ňom nevyskytli žiadne dočasne uložené dáta, ktorá by mohla byť pri použití tohto kódu iným procesom, omylom priradená nesprávnemu procesu. Všetky potrebné hodnoty vlastného procesu boli uložené cez pointer do autonómnej oblasti daného procesu. Tým pádom bol kód programu súčasne prístupný viac procesom naraz a mohol v pamäti existovať iba raz pre viac súčasne bežiacich procesov. Dnes by sa povedalo, že všetky dáta procesu bola ako referenčná typy uložená v autonómnej oblasti daného procesu.
Všetko bolo napísané síce v assembleri, ale jednalo sa o makro assembler a pre sálový stroj, takže úroveň možností bola podstatne ďalej než u assembleri dnešných PC. Pozriem Ak sa na problém dnešnom pohľadom objektového programovania, tak procesy "likvidácia" (ktorých bolo celkovo 10), boli ako inštancia triedy likvidácia vygenerované v hlavnom (riadiacom) programu (Monitor). Vlastné ale funkčnosť (aplikačné procedúra "likviduj") bola pre triedu likvidácia spoločná v module likvidácie. Celé riešenie si možno predstaviť ako desať účtovných, ktorí sedia vedľa seba, účtujú a hneď si odovzdávajú výsledky.
Hlavný program mal okrem riadenia procesov ešte dohliadať na spúšťanie tzv. Iteračných kolies. Tie vznikali tým, že ak vám prišiel nejaký kredit, bolo nutné sa pozrieť, či sa nedá zaplatiť niečo ďalej. Ak áno, bolo spustené ďalšie kolo. Limit bol desať kôl, ale nikdy sme ho nedosiahli. Účinnosť bola ale tak veľká, že sme vždy skončili skôr.
Výsledky
Zaujímavé bolo, že program pri opakovaní na rovnaké vstupné dáta (jednalo sa o dávkový program), nedával rovnaké výsledky. To bolo spôsobené tým, že náš počítač v porovnaní s dnešným PC bol pomaly lezúci šnek s minimálnou pamäťou (cca 300 000 inštrukcií / sa 1 Mb vnútornej pamäte). A tak sme museli hľadať také postupy, aby sme z neho vyťažili čo najviac. Štatistika spracúvaných údajov hovorila, že 60-70% platobných transakcií je v rámci okresu tj. Jednej pobočky. Tak sme premýšľali či toto nemožno nejako využiť. Náš "sálový" počítač totiž vedel súčasne pracovať tj. Čítať a zapisovať dáta na troch nezávislých sadách diskov. A tak nás napadlo, že keby sme pri vytváraní (dnes by sa povedalo databázy) zapisovali dáta tak, že po naplnení celej jednej plochy na disku by sme ďalšie dáta zapisovali na ďalší fyzický disk, potom na tretí a zase znova na prvý, tak by sme získali databázu na troch fyzických nosičoch. Ak by sme ich potom dali každý na iný kanál, tak by sme mohli v 60% prípadov súčasne čítať a zapisovať dáta na troch diskoch naraz. Tak sme tento nápad realizovali. Našich desať procesov - likvidátorov, čítalo súčasne dáta z troch nezávislých diskov.
Vďaka tomu ale začalo záležať na tom, ako v okamihu štartu boli voči sebe natočené tieto disky a akú vzájomnú rýchlosťou sa točili. Podľa toho, ako sa dotáčely na začiatky stôp, dochádzalo na čítanie a rozbiehaní sa likvidácia jednotlivých procesov. Tie potom prinášali inak kredit a všetko potom prebiehalo podľa aktuálneho stavu už spracovaných dát, ktorý nebol pri opakovaní prakticky nikdy rovnaký. Celé to malo charakter, ako keď sa spýtate na najrýchlejšiu cestu na letisko a dostane odpoveď podľa stavu v danom okamihu. Zakaždým je odpoveď trochu iná, ale veľmi sa podobajú. Pretože pri opätovnom spustení sa vám prakticky nemohlo podariť nastaviť absolútne zhodné počiatočné podmienky a ani zaručiť zhodný priebeh výkonu, tak logicky dochádzalo k "rôznym" výsledkom.
Na uvedenom príklade je vidieť, že pri riešení nejakej problematiky je najdôležitejšie si ujasniť, čo sa vlastne chce a prečo. Až potom máte možnosť vyhľadať zodpovedajúce riešenie. Nerozumná maximalizácia požiadaviek respektíve funkčnosti od zadávateľa, môže nakoniec celý zámer zhatiť. Predstavte si, že sa snažíte odhadnúť čísla v Športke. Načo požadovať program, ktorý je schopný určiť čo padne za čísla, keď bohato stačí, keby v 50% prípadov ich určil správne len 80%.
