Kilka osobnikow prosilo mnie o wytlumacznienie tematu (hehe, tak zamydlalem, ze uwierzyli ze naprawde wiem o czym mowie, ale przynajmniej jestem szczery;)) ), wiec od razu wysylam do wszystkich potencjalnie zainteresowanych



Pobieranie 11,42 Kb.
Data17.12.2017
Rozmiar11,42 Kb.

Kilka osobnikow prosilo mnie o wytlumacznienie tematu (hehe, tak zamydlalem, ze uwierzyli ze naprawde wiem o czym mowie, ale przynajmniej jestem szczery ;)) ), wiec od razu wysylam do wszystkich potencjalnie zainteresowanych. Jakbym nie mial racji tu lub owdzie to prosze o przeslanie sprostowania.
Ok ,wiec puki jeszcze jezdem drzeswy do pozdaram siem wytlumaczyc jag najlebiej potrafiem.
Co to ten cholerny semafor, jak ktos jeszcze nie wie to mozna to sformulowac w nastepujacy sposob:
"Semafor to narzędzie synchronizacji, które znajduje zastosowanie w rozwiązywaniu problemu sekcji krytycznej z udziałem n procesów. Jest to zmienna całkowita która oprócz nadawania wartości początkowej jest dostępna
tylko za pomocą dwu standardowych niepodzielnych operacji czekaj i sygnalizuj."
Cholera wie dlaczego przy pomocy tylko takich dwoch funkcji i jedna zmienna a nie dla calego programu np. tablica wykonanych procesow.... Coz, nie wiem, ale skoro tak jest to trzeba tak dzialac.

Na poczatku warto byloby dodac , ze w momencie dzialania wspolbieznego nie jestesmy w stanie stwierdzic, ktory z procesow wykona sie najpierw. Gdyby bylo wiadomo to nie byloby problemu ;). Niestety nie wiadomo, i tu jawi sie


problem. Jesli mamy (tak jak w zadaniu , ktore miec bedziemy) zapodane , ze instrukcje w wykonywanych procesach maja okreslona kolejnosc to z pomoca przyjda nam owe :"semafory":, inaczej nie da sie tego zrobic. Piszac prosty program (powiedzmy w Dosie), ktory skladal by sie z 3 procedur: start, cala_robota i stop (w takiej kolejnosci mialyby sie wykonywac) ale wlasciwie kolejnoscie faktycznej wykonywania nie bylibysmy w stanie przewidziec (naturalnie cos takiego jest nierealne - podaje narazie prosty przyklad dla ludzi ,do ktorych caly czas to nie trafia). Co bysmy zrobili ?Ano pewnie cos takiego:
if wykonano cala_robota to wykonaj stop
elseif
wykonano start to wykonaj cala_robota
else
wykonaj start

Semafory robia cos takiego, lecz nieestety nie w tak prosty sposob. Tutaj trzeba sobie ustalic ilosc semaforow dla calego problemu (w zaleznosci od proponowanego rozwiazania ilosc moze byc rozna, kwestia interpretacji)a


nastepnie sprytnie wykombinowac sobie jak wywolywac funkcje sterujace semaforami.
Mamy je dwie i sa zdefiniowane nastepujaco (przynajmniej Krus tak podawal):

czekaj(semafor){


while semafor <=0 do nothing
semafor = semafor -1
}

sygnalizuj(semafor){


semafor=semafor+1
}

Inaczej f. czekaj mozna to zrozumiec jako : "przerwij wykonywanie kodu procesu az wartosc semafora podanego parametrem bedzie > 0. Wtedy zmniejsz ja o 1". Sygnalizowanie semafora zwieksza wartosc o 1. Po kiego wala to ?


Otoz w ten sposob odpowiednio manipulujac wartosciami semaforkow sterujemy kolejnoscia wykonywania danych procesow. Jesli na poczatku ustawimy np.
semafor:
sem1=0;
a w jakims procesie w kodzie bedzie :
czekaj(sem1);
to dalej za cholere sie nie wykona dopuki jakis inny proces nie
zasygnalizuje sem1 ;)) czyli nie zrobi:
sygnalizuj(sem1);
Majac te informacje jedyna rzecza , ktora teraz trzeba wypocic, to sposob w jaki bedziemy czekac i sygnalizowac semafory by uzyskac pozadany efekt. Zrobimy sobie prosciutki przykladzik (pozniej bedzie trudniejszy , byl na
konsultacjach wiec bedzue na 1000% dobrze, a ma haczyk i moze sie cos takiego trafic).
Z braku interface'u graficznego musicie zaprzac wyobraznie do roboty.
Kolejnosc wykonywania instrukcji:
S1-> S2->S3.
Czyli na wykonanie S1 czeka S2 a na wykonanie tego czeka sobie S3. Mamy 3 procesy (P1,P2,P3), z ktorych kazdy wykonuje po jednej instrukcji, wiec kolejno P1-S1,P2-S2,P3-S3.
Przykladowy kod procesu wyglada nastepujaco
P1:
... // takie kropki to jakas poprawna instrukcja
...
...
S1
..
...
...

Czyli inaczej mowiac gdzies w kodzie P1 znajduje sie wywolanie instrukcji S1. Gdzie to nas nie interesuje. Co mamy zrobic to to, by instrukcje Sx (czyli de facto procesy je wywolujace) odpalaly sie w zadanej kolejnosci.


Wiec widac golym (kurde tylko zeby mi nie bylo, ze tylko z jednym mi się kojarzy !) okiem widac, ze proces P3 musi poczekac na wykonanie P2, a ten na wykonanie P1. P1 nie czeka na nic - wykonuje sie jako pierwszy. Aby to
zrealizowac potrzebne beda 2 semafory. Trza je bedzie zadeklarowac na pcozatku, czyli:
sem=0;
sem=0;
Dajemy zero, gdyz wartosc wieksza od zera spowoduje, ze w procesie gdze znajdzie sie wywolanie czekacj(sem1) w wypadku gdy sem1=1 nie czekalby gowniarz, tylko by sie wykonal.
Nastepnie mamy 3 procesy (sorx za mala przejzystosc):
P1 P2 P3
.... .... ....
.... ..... .....
S1 S2 S3
..... ..... ......
..... ..... .....

Kombinujemy z semaforami tak (pamietamy, ze oba na starcie sa 0 i P1 nie czeka na nic - pierwszy sie wykonuje): P2 poczeka az P1 ustawi sem1 na 1 by mogl sie wykonac. Wtedy sam ustawi sem2 na 1 by mogl sie wykonac P3. Czyli zachowamy porzadana kolejnosc. Ustawienie na 1 zrealizujemy sygnalizujac semafor ( sygnalizuj(sem1)). Proste, nie ?


P1 P2 P3
.... .... ....
.... czekaj(sem1) czekaj(sem2)
S1 S2 S3
syg(sem1) syg(sem2) ......
..... ..... .....

Dzialanie takiego schematu bedzie proste. Na poczatku obojetnie ktory proces bedzie wykonywany - wlasciwie wykona sie tylko P1. P2 i P3 maja czekaj(semx) i doopa. Nie wykonaja sie dalej , bo sem1 i sem2 sa 0. Dopiero gdy P1 wykona sie po sygnalizuj(sem1) wartosc semafora sem1 zwiekszy sie do jednego, co umozliwi P2 wykonanie instrukcji S2 i sygnalizacje semaforka sem2. A to z kolei da wolna reke procesowi P3, ktory juz nie bedzie czekal bo sem2 =1 i wykona sie do konca. Nic nie sygnalizuje bo juz za P3 nic nie wiec można olac. Tak samo P1 na nic nie czeka bo jest pierwszy. Tak sie to generalnie robi. Mam nadzieje, ze majacy problemy zrozumieli (Ma(r)x , kapujesz o co biega ? Bo jak nie to ja juz nie wiem co zrobic bys zrozumial ... moze mlotkiem ? ;)) )


Ok, ale jak wpsomnialem moga sie trafic sytuacje z "haczykiem". Narazie mam dwie takie, ktore obrazuje jeden przyklad z konsultacji. Sytuacje watpliwe wystepuja w momencie, gdy jeden proces czeka na wykonanie kilku oraz kilka procesow czeka na wykonanie jednego. Zadana kolejnosc wykonywania instrukcji jest nastepujaca:
S1->S2,S3,S4->S5.
Sytuacje wyglada odrobine podobnie . S2,S3,S4 po S1, a S5 po S2,S3 i S4.
Sprobujmy rozwiazac to starym sposobem (2 semafory sa potrzebne do tego):
sem1=0;
sem2=0;
P1 P2 P3
P4 P5
.... ...... ......
..... .......
..... czekaj(sem1) czekaj(sem1)
czekaj(sem1) czekaj(sem2)
S1 S2 S3
S4 S5
syg(sem1) syg(sem2) syg(sem2) syg(sem2)
.......
..... ...... ........
......... .......

Jak to dziala? Na poczatku jest ok. Napewno bedzie sie w stanie wykonac tylko P1 (na nic nie czeka - jest pierwszy). Sygnalizuje sem1 (tera sem1=1). Coz sie tutaj teraz dzieje ? Otoz jako , ze sem1=1 to P2 moze sie swobodnie wykonac zgodnie z kolejnoscia. Ale P3 i P4 ROWNIEZ MOGA SIE WYKONAC TYM RAZEM JUZ NIEZGODNIE Z KOLEJNOSCIA. Przeciez sem1=1 wiec moga sie wykonac P2,P3 lub tez P4. LUB bo ktorykolwiek z nich bys sie nie wykonal to czekaj(sem1) zmieni wartosc sem1 z powrotem na 0 (pamietacie kod funkcji ? zezwala na dalsze dzialanie ale zmniejsza wartosc semafora o 1, NIE NA 0, ale zmniejsza o 1. Czyli jesli sem1=1 to zmieni go na zero . Bardzo istotne jest pamietanie o tym, ze czekaj(sem) nie robi w kodzie sem=0 tylko


sem=sem-1). Wracajac, jesli nawet wykona sie P2, to P3 i P4 nie beda mogly sie wykonac bo sem1 znow rowny jest 0, ale za to sem2=1 wiec wykona sie P5. Czyli mamy sytuacje bledna , bo kurde dwa z 3 procesow (P2,P3,P4) sie nie wykonaja ... Aby temu zaradzic zmienimy nieco kod procesow:
sem1=0;
sem2=0;
P1 P2 P3
P4 P5
.... ...... ......
..... .......
..... czekaj(sem1) czekaj(sem1)
czekaj(sem1) czekaj(sem2)
S1 S2 S3
S4 S5
syg(sem1) syg(sem2) syg(sem2) syg(sem2)
.......
syg(sem1) ...... ........
......... .......
syg(sem1) ...... ........
......... .......
..... ...... ........
......... .......

W tym momencie napewno wykonaja sie wszystkie procesy. Jesli ktos się zastanawia dlaczego 3 razy zwiekszamy wartosc, a nie lepiej moze od razu przypisac np. sem1=3 to od razu odpowiadam, ze gdyby sem1 byl >0 to wykonal


by sie jakikolwiek proces za wyjatkiem P5 (czekaja na sem1 (a sem1>0)). Wszystko fajnie pieknie. P1 sie wykonal, sem1=3 i co dalej. Proces P2 po wykonaniu zmniejsza wartosc sem1 o 1 (wiec sem1=2). P3 po wykonaniu zostawia
sem1=1 a P4 wykonuje sie i czekaj(sem1) daje sem1=0; No i proces P5 moze się wykonac. Pomyslicie, ze jest w pozadalu, a tu doopa blada. Zalatwilismy pierwszy haczyk, gdzie wiele procesow czeka na wykonanie jednego (poprzez wielokrotna sygnalizacje) ale pamietacie ? zostal jeszcze jeden - przeciez w rzeczywistosci P5 czeka na wykonanie 3 - P2,P3 i P4. My niestety zrealizowalismy wariant, ze P5 czeka na wykonanie jakiegokolwiek i tylko w
przypadku maxymalnego farciora udaloby sie wykonac instrukcje Sx w odpowiedniej kolejnosci. Niestety obojetnie ktory z procesow (P2,P3 czy P4) sie wykona zwiekszy nam sem2 do wartosci 1. No i teraz P5 moze sie spokojnie
wykonac bo czeka wlasnie do momentu az sem2>0. I gnat, bo zasraniec miał wykonywac sie na samym koncu. Jak to zalatwic? Anpo sposob jest prosty. Tak:
sem1=0;
sem2=-2;
P1 P2 P3
P4 P5
.... ...... ......
..... .......
..... czekaj(sem1) czekaj(sem1)
czekaj(sem1) czekaj(sem2)
S1 S2 S3
S4 S5
syg(sem1) syg(sem2) syg(sem2) syg(sem2)
.......
syg(sem1) ...... ........
......... .......
syg(sem1) ...... ........
......... .......
..... ...... ........
......... .......

hehe, banalna sprawa. Ale najciemniej jest pod latarnia. Wiec P2 sie wykona zostawiajac sem2=-1. P3 daje sem2=0 a P4 dopiero sem2=1 i P5 tylko wtedy moze sie wykonac. Zaznaczam dobitnie , ze proc wcale nie musi probowac


wykonywac P2 po P1 !!!! Jeszcze raz podkreslam, ze wykonywanie jest mniej/bardziej losowe, wiec po to nam te zasyfiale semafory.
Ok, to by bylo na tyle. Jak ktos nie zalapal, to ma jeszcze 1 dzien, ale sukcesow nie wroze (z drugiej stronu do doopy ze mnie wrozka ;)))) ). Jakbym sie gdzies walnal to wysylac sprostowanie.
: pliki2 -> Semestr%204 -> Systemy%20Operacyjne%202%20[SO2] -> Undernet WSO2 MaxPack
Undernet WSO2 MaxPack -> Zajęcia 5 zakres prac I materiały pomocnicze zakres prac
Undernet WSO2 MaxPack -> Zajecia 1 zakres prac I materialy pomocnicze
Undernet WSO2 MaxPack -> Zajęcia 13 zakres prac I materiały pomocnicze zakres prac
Undernet WSO2 MaxPack -> Zajęcia 10 zakres prac I materiały pomocnicze zakres prac
Undernet WSO2 MaxPack -> Zajecia 1 zakres prac I materialy pomocnicze
Undernet WSO2 MaxPack -> Zajęcia 6 zakres prac I materiały pomocnicze zakres prac
Undernet WSO2 MaxPack -> Zajęcia 4 zakres prac I materiały pomocnicze zakres prac
Undernet WSO2 MaxPack -> Zajęcia 9 zakres prac I materiały pomocnicze zakres prac
Systemy%20Operacyjne%202%20[SO2] -> Koordynacja procesóW
Undernet WSO2 MaxPack -> Zajęcia 8 zakres prac I materiały pomocnicze zakres prac




©operacji.org 2019
wyślij wiadomość

    Strona główna