Uvod v paralelne procese


Problemi paralelnih procesov
Sočasno izvajanje več programskih procesov odpira dodatne
probleme, ki jih pri navadnih programih ne zasledimo, četudi so ti programi
lahko zelo kompleksni. Večina teh problemov terja pravilno sinhronizacijo
paralelnih procesov. Stvar postane še toliko težja, če ti programski procesi
ne potekajo na istem računalniku. Oglejmo si najprej tipične
probleme, zatem pa še mehanizme, ki
jih moramo zato uporabiti.
Problem kritičnih sekcij
Problem nastopi, ko več sočasnih procesov občasno terja dostop
do skupnih računalniških virov ali skupnih podatkovnih struktur, ki jih
želi spreminjati. Ko dobi proces dostop do takih skupnih podatkovnih struktur,
je v takoimenovani
kritični sekciji .
Zagotoviti moramo,da je v času, ko je nek proces v
kritični sekciji, drugim procesom dostop v to sekcijo prepovedan.
Ostali procesi lahko medtem paralelno potekajo, v primeru
zahteve po vstopu v zasedeno kritično sekcijo pa čakajo. Ob sprostitvi
kritične sekcije lahko vanjo vstopi lepo en proces.
Medsebojno izobčenje sočasnih programskih procesov lahko
zagotovimo s posebnimi konstrukti.
Primer:
Vzemimo sistem z več terminali. Sistem naj "šteje število
vrstic, vtipkanih v enem dnevu". V ta namen imamo skupno sistemsko spremenljivko
lineCount. Delo posameznih uporabnikov za terminali nadzorujejo ločeni
procesi. Kadarkoli nek uporabnik na svojem terminalu vtipka , se izvedejo
v sklopu njegovega programskega procesa stavki naslednje vsebine:
load lineCount
add 1
store lineCount
Vzemimo primer, da lineCount že vsebuje vrednost 1234 in
da proces A pravkar izvaja ukaz add, ki vrednost v akumulatorskem registru
poveča na 1235. Naj v tem trenutku proces B (zaradi enakega štetja) prav
tedaj izvede operacijo load. Podatke 1235 v akumulatorju se zato spet pokvari
na 1234 in, če bi v tem hipu proces A izvedel še zadnjo operacijo (store),
bi očitno shranil v spremenljivko lineCount zgrešeno vrednost.
Problem lahko rešimo, če je dostop
posameznih programskih procesov do takih skupnih spremenljivk, kot je v
našem primeru lineCount, ekskluziven.
Podobne probleme zasledimo tudi na primer pri večuporabniškem
dostopu do podatkov v podatkovnih bazah, pri (sistemskem) dostopu do skupnih
podatkovnih struktur (operacijskega sistema) v večprocesnih operacijskih
sistemih itd.
Problem omejenega pomnilnika (Proizvajalec - porabnik)
To je v bistvu problem dveh sočasnih procesov, pri katerem
en proces (proizvajalec) generira podatke, ki jih mora uporabljati drug
proces (uporabnik). Da bi bilo izvajanje obeh procesov med seboj čimbolj
neodvisno,
shranjuje proces - proizvajalec podatke v skladišče (medpomnilnik, buffer),
drug proces pa jih iz tega skladišča jemlje v istem zaporedju.
Tako sožitje dveh procesov zasledimo zelo pogosto v
okviru modulov operacijskih sistemov, predvsem v v modulih, ki so odgovorni
za vhodno- izhodne operacije računalnika.
Seveda je "skladišče" omejeno (če drugega ne že z velikostjo
pomnilnika). Proizvajalec lahko medpomnilnik napolni le do neke meje. Pred
nadaljnjim polnjenjem mora počakati, da ga "porabnik" vsaj malo izprazni.
Prav tako ne sme proces - porabnik nič "vzeti iz medpomnilnika", če ni
že vanj kaj vložil proces - proizvajalec. Potrebna je koordinacija delovanja
obeh procesov.
Omejenemu pomnilniku pravijo včasih tudi krožni
medpomnilnik (ring- buffer), saj ga začne proizvajalec, potem, ko
je prišel do konca, spet pomniti "na začetku". Analogno se dogaja s porabnikom:
Ko vzame z medpomnilnika zadnji element, gre naslednjega iskati spet na
"začetek". V računalniškem smislu uporabljata oba procesa kazalca
na tekoči element v tem medpomnilniku. Pomembno je, da kazalec procesa-
porabnika ne prehiti kazalca proizvajalca
(in obratno).
Problem pisalcev in bralcev
Imejmo več sočasnih procesov, ki lahko berejo ali popravljajo
isto podatkovno strukturo. Struktura naj bo dovolj kompleksna, da je posamezen
proces ne more prebrati ali zapisati v "enem koraku". To pomeni, da bi
lahko nek proces začel zapisovati novo verzijo, med samim zapisovanjem
pa bi lahko nek drug proces strukturo "prebral". Podatki, ki bi jih tako
dobil, bi bili lahko delno že "novi", delno pa še "ta stari", skratka nekonsistentni.
Da
ne pride no nekonsistence podatkov, moramo zagotoviti, da v obdobju, ko
nek proces zapisuje nove podatke, noben drug proces ne more ne brati ne
pisati v to strukturo. Seveda pa lahko več "bralcev" sočasno bere.
Potrebna je torej pravilna koordinacija pisalcev in bralcev.
Problem smrtnega objema
Obravnavali bomo različne tehnike medsebojne sinhronizacije
paralelnih programskih procesov. Ta se doseže tako, da proces, ki naj bo
sinhroniziran z nekim drugim, v danem trenutku počaka na nek dogodek (event).
Prav možno je, da do tega dogodka iz različnih razlogov ne more priti.
Pravimo, da se je en ali več paralelnih procesov znašlo v smrtnem objemu
(deadlock). Oglejmo si nekaj možnih vzrokov za tak pojav ter ugotovimo,
kako ga lahko preprečujemo.
Do smrtnega objema lahko pride, ko na primer dva procesa
čakata drug na (dogodek) drugega. Ker pa sta oba s tem blokirana, do odrešilnega
dogodka ne v enem ne v drugem procesu ne pride. Preprost zgled je lahko
naslednji. Imamo dva programska procesa, ki za svoje delo potrebujeta dve
periferiji. Vsak si že lasti eno in čaka na drugo. Problem ponazoruje slika.
Kateri pogoji so potrebni za nastop smrtnega objema?
Kako preprečujemo nastop smrtnega objema?
Primer v Javi
Problem stradanja
Sorodni problem smrtnemu objemu je problem stradanja
ali nedoločenega zapostavljanja. Včasih mu tudi rečemo problem živega objema
(livelock). Nek proces čaka na neko sredstvo, vendar je (morda zaradi nižje
prednosti) stalno zapostavljen in nikdar ne pride
na vrsto. Tipičen primer živega objema lahko zasledimo pri slabo
zasnovanem algoritmu razvrščanja procesov (scheduling). Nek proces z nizko
prioriteto morda nikdar ne pride na vrsto, ker imajo prednost procesi z
višjo prednostjo. Ta problem lahko rešujemo na primer tako, da s staranjem
prednost takemu procesu zvišujemo.
Navedene probleme blokiranja nekega procesa (nedoločeno
zapostavljanje, smrtni objem) zasledimo na primer pri operacijskih sistemih
računalnikov. Operacijski sistem je predvsem "upravnik sredstev" (resource
manager) računalniškega sistema. Za ta sredstva pa istočasno lahko konkurira
večparalelnih programskih procesov.
Filozofi na večerji 1,
2,

