Komunikaty Wstep 8 id 243824 Nieznany

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 1

5. Komunikaty, model komunikuj

ących się procesów

5.1 Model procesów i komunikatów

Model procesów i komunikatów skonstruowany jest w oparciu o
nast

ępujące reguły:

Aplikacja sk

łada się ze zbioru procesów sekwencyjnych.

Procesy mog

ą być wykonywane równolegle.

Proces wykonuje si

ę sekwencyjnie i używa swej pamięci

lokalnej.

Proces komunikuje si

ę z otoczeniem za pomocą

komunikatów. S

ą dwie podstawowe operacje

komunikacyjne: wys

łanie komunikatu i odbiór komunikatu.

Procesy mog

ą być przydzielone do procesorów w różny

sposób. Poprawno

ść działania aplikacji nie powinna

zale

żeć od tego podziału.



Proces

P1

Proces

P4

Proces

P3

Proces

P2

Proces

P5

Proces

P6

Komunikat

Proces

Procesor 1

Procesor 2

Procesor 3

Aplikacja równoleg

ła jako zbiór komunikujących się procesów

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 2

5.2 Komunikaty

Mo

żliwość przekazywania komunikatów pomiędzy procesami

jest fundamentaln

ą własnością większości systemów

operacyjnych.

Je

śli pomiędzy dwoma maszynami istnieje jakikolwiek sposób

komunikacji (sie

ć lokalna, sieć rozległa, bezpośrednie łącze,

wspólna pami

ęć, itd.) na pewno daje się przesłać komunikat

pomi

ędzy procesami wykonywanymi na tych maszynach.


Przes

łanie komunikatu pomiędzy procesami jest przesłaniem

pomi

ędzy nimi pewnej liczby bajtów według ustalonego

protoko

łu. Przesłanie komunikatu jest operacją atomową.

Z przesy

łaniem komunikatów wiążą się co najmniej trzy

problemy:

problem synchronizacji nadawcy i odbiorcy (kto i kiedy
czeka),

problem adresowania (jaki system adresacji),

problem identyfikacji (czy procesy znaj

ą swoje

identyfikatory),

problem przep

ływu danych (w jedną czy dwie strony),

problem zapewnienia niezawodnego przes

łania przez

zawodny kana

ł komunikacyjny.


Do zapewnienia komunikacji potrzebne s

ą przynajmniej dwie

funkcje interfejsowe – wysy

łająca i odbierająca komunikat.


Wys

łanie komunikatu: send(id_odb, void *bufor, int ile)

Odbiór komunikatu:

receive(id_nad, void *bufor, int ile)



PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 3

P1

P2

Proces nadaj

ący

Komunikat

send(P2,&bufor, ile)

receive(P1,&bufor, ile)

Proces odbieraj

ący


Przesy

łanie komunikatów pomiędzy procesami P1 i P2



Przesy

łanie komunikatów realizowane jest przez system operacyjny.

Funkcje systemu operacyjnego:

1. Zapewnienie transmisji komunikatu pomi

ędzy komputerami i ukrycie

szczegó

łów tej transmisji.

2. Wykrywanie i korygowanie b

łędów transmisji.

3. Sk

ładanie i rozkładanie komunikatów w pakiety transmitowane przez sieć.



P1

send(P2,&buf, ile)

Proces

odbierający

Komunikat

System

operacyjny

Sprzęt

P2

receive(P1,&buf,ile)

System

operacyjny

Sprzęt

Sieć

Proces

nadający

Komputer 1

Komputer 2

Poziom systemu

operacyjnego

Poziom aplikacji

Droga komunikatu od procesu P1 na komputerze 1 do procesu P2 na komputerze 2.

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 4

5.3 Komunikacja synchroniczna i asynchroniczna

5.3.1 Synchronizacja

Komunikacja synchroniczna

Proces wysy

łający jest blokowany do czasu otrzymania potwierdzenia że

proces docelowy otrzyma

ł wysyłany komunikat

Gdy w momencie wykonania funkcji

receive brak jest oczekującego

komunikatu, proces odbieraj

ący jest wstrzymywany do czasu nadejścia

jakiego

ś komunikatu. Gdy jakiś komunikat oczekuje, proces odbierający nie

jest blokowany.


P1

P2

Komunikat

send

receive

Potwierdzenie

odbioru

P1

P2

Komunikat

send

receive

Potwierdzenie

odbioru

Przypadek 1

Przypadek 2

Blokada

Blokada


Komunikacja synchroniczna pomi

ędzy procesami P1 i P2




Komunikacja asynchroniczna

Proces wysy

łający komunikat nie jest blokowany.

Proces odbieraj

ący jest wstrzymywany do czasu nadejścia komunikatu (wersja

blokuj

ąca) lub też nie jest wstrzymywany (wersja nie blokująca). Informacja

czy odebrano komunikat czy te

ż nie, przekazywana jest jako kod powrotu

funkcji odbieraj

ącej.

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 5

P1

P2

Komunikat

send

receive

P1

P2

Komunikat

send

receive

Blokada

Przypadek 1

Przypadek 2 - wersja

blokujaca

Komunikacja asynchroniczna pomi

ędzy procesami P1 i P2




Rodzaj
komunikacji

Blokada przy wysy

łaniu

Blokada przy odbiorze

Synchroniczna Tak

Tak

Asynchroniczna Nie

Tak - wersja blokuj

ąca

Nie - wersja nie blokuj

ąca

Tab. 1 Definicja komunikacja synchronicznej i asynchronicznej

5.3.2 Buforowanie

Przy transmisji asynchronicznej konieczne jest buforowanie po stronie wysy

łającej.

Powstaje pytanie:

Jaka powinna by

ć pojemność tego bufora ?

Co zrobi

ć gdy bufor się przepełni ?


Post

ępowanie w przypadku przepełnienia bufora:

Zablokowa

ć proces wysyłający.

Funkcja wysy

łająca komunikat kończy się błędem.




Synchroniczna

Asynchroniczna

Obs

ługa błędów

Testowanie

kodu

powrotu

Konieczna

obs

ługa

wyj

ątków

Buforowanie po stronie
wysy

łającej

Nie

Tak

Szybko

ść

przetwarzania

Mniejsza

Wi

ększa

Porównanie komunikacji synchronicznej i asynchronicznej



PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 6

5.4 Adresowanie

Do adresowania procesu docelowego stosuje si

ę następujące rozwiązania:

1. PID procesu
2. IP maszyny + numer portu
3. Nazwy symboliczne procesów


Aby zastosowa

ć nazwy symboliczne konieczny jest serwer nazw (ang. Name

serwer).

Proces klienta

(88,24)

Serwer nazw

(100,8)

Serwer usługi

(123,48)

rejestracja nazwy "/BAZA"

potwierdzenie

nazwa symb. "/BAZA"

nazwa pełna (123,48)

komunikat do (123,48)

odpowiedź

Baza nazw

REJESTRACJA

KOMUNIKACJA

LOKALIZACJA

Komunikacja procesu klienta z serwerem us

ługi „/BAZA”




Powstaje pytanie sk

ąd znana jest lokalizacja serwera nazw ?.

1. Lokalizacja serwerów nazw jest ustalona i podana jako parametr instalacyjny

systemu

2. Serwery nazw rozg

łaszają swą lokalizację innym węzłom.


5.5 Identyfikowanie procesów

We wzajemnej komunikacji procesów wyst

ępuje problem identyfikacji.

Przyk

łady:

1. Po

łączenie telefoniczne – dzwoniący musi znać numer tego do kogo dzwoni

ale odbiór nie wymaga znajomo

ści dzwoniącego.

2. Tablica og

łoszeń – każdy może umieścić ogłoszenie i każdy może je odczytać

lub zdj

ąć


W praktyce stosowane s

ą różne rozwiązania:

1. Kana

ł symetryczny (dedykowany) – aby się skomunikować procesy muszą

zna

ć swe identyfikatory (Occam).

2. Kana

ł niesymetryczny - klient musi znać identyfikator serwera ale nie musi

by

ć odwrotnie (ADA, komunikaty systemu QNX).

3. Rozsy

łanie komunikatów – komunikaty umieszczane są w globalnej

przestrzeni sk

ąd każdy może je pobrać (Linda)

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 7


5.6 Komunikacja połączeniowa i bezpołączeniowa


Komunikacja połączeniowa

1. Dwa procesy ustanawiaj

ą połączenie w którym występuje informacja

adresowa

2. Wymieniaj

ą dane używając tylko identyfikatora połączenia

3. Roz

łączają się


Cz

ęsto połączenie jest kontrolowane w sensie:

- Możliwości przesyłania danych
- Poprawności danych

Komunikacja bezpołączeniowa
W ka

żdym przesłaniu występuje pełna informacja adresowa

P1

P2

Komunikaty

Polaczenie

Czekanie

P1

P2

Komunikat

send

receive

Komunikacja polączeniowa

Rozlączenie

Komunikacja bezpolączeniowa


5.7 Przeterminowania

Konieczno

ść synchronizowania procesów wymusza konieczność ich blokowania.

Procesy s

ą blokowane w oczekiwaniu na pewne zdarzenie. Z różnych powodów

(b

łędy, uszkodzenia) zdarzenie to może nigdy nie nadejść. Spowoduje to trwałą

blokad

ę procesu. Aby temu zaradzić stosuje się przeterminowanie (ang. Timeout)

oczekiwania.

Wys

łanie komunikatu:

send(id_odb, bufor_nad, ile, timeout)

Odbiór komunikatu:

receive(id_nad, bufor_odb, ile, timeout)

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 8

Gdy proces nie zostanie samoistnie odblokowany po czasie

timeout

zrobi to

system operacyjny. Funkcja zwróci kod b

łędu.

P1

P2

receive

Blokada

receive

Blokada


Procesy P1 i P2 pozostaj

ą zablokowane

5.8 Reprezentacja danych

Wysy

łający dane używa specyficznych typów danych jak:

znaki, liczby int, liczby real, sta

łe boolean, struktury, tablice, teksty róznych formatów,

obiekty.

Na poziomie sieci transmitowane s

ą bajty


Przyk

ład

Maszyna M1 - 32 bitowa, system "big endian"
Maszyna M2 - 16 bitowa, system "little endian"

"big endian" - skrajny lewy bit (o najni

ższym adresie) jest najbardziej znaczący

"little endian" - skrajny lewy bit (o najni

ższym adresie) jest najmniej znaczący


M1 wysy

ła 32 bitową liczbę x do M2. Aby M2 zinterpretowała liczbę prawidlowo

nale

ży:

Obci

ąć liczbę x do 16 bitów

Przestawi

ć bity


Inne przyk

łady

Tekst ASCII i Unicode


Mo

żliwe sposoby transformacji danych:

Maszyna M1 konwertuje dane do postaci M2 a nast

ępnie je wysyła

Maszyna M2 konwertuje dane otrzymane z M2 do swojej reprezentacji

Przed wys

łaniem maszyna M1 konwertuje dane do pewnej zdefiniowanej

zewn

ętrznej reprezentacji (ang. external reprezentation).

Maszyna M2 po odebraniu konwertuje dane z zewnetrznej reprezentacji do

swojej.

Wniosek: transformacja danych jest konieczna gdy systemy s

ą heterogeniczne

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 9

Transformacja postaci danych przy IPC nazywa si

ę przetaczaniem danych (ang.

data marshalling)

Kroki przetaczania danych
Przy nadawaniu
Serializacja danych
Konwersja do zewn

ętrznej reprezentacji


Przy odbiorze
Konwersja z zewn

ętrznej do wewnętrznej reprezentacji

Deserializacja danych


PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 10

5.9 Kolejki komunikatów

Kolejka komunikatów Q posiada nast

ępujące własności:

Posiada okre

śloną pojemność N komunikatów (długość bufora komunikatów).

Posiada nazw

ę którą procesy mogą zidentyfikować.

Procesy mog

ą umieszczać komunikaty w kolejce (np. za pomocą operacji

Send(Q,buf,ile)). Gdy kolejka jest pe

łna proces wysyłający się blokuje.

Procesy mog

ą pobierać komunikaty z kolejki (np. za pomocą operacji

Receive(Q,buf,ile)). Gdy kolejka jest pusta proces odbieraj

ący się blokuje.

Wi

ęcej niż jeden proces może czytać lub pisać z/do kolejki.



P1

P2

Proces nadaj

ący

Proces odbierajacy

send(Q,&bufor, ile)

receive(Q,&bufor, ile)

N

Kolejka Q

Max

Procesy P1 i P2 komunikuj

ą się za pomocą kolejki Q



Przebieg operacji zapisu i odczytu zale

ży od liczby N komunikatów w kolejce i od jej

pojemno

ści Max.


Liczba komunikatów N
w kolejce Q

Wys

łanie komunikatu

Send(Q,buf, ile)

Odbiór komunikatu
Receive(Q,buf,ile)

N = Max

Blokada lub
sygnalizacja b

łędu

Bez blokady

0< N < Max

Bez blokady

Bez blokady

N = 0

Bez blokady

Blokada

lub

sygnalizacja

b

łędu

Przebieg operacji na kolejce w zale

żności od liczby komunikatów N w jej buforze


Proces 1 dokonuje zapisu do pe

łnej kolejki i zostaje zablokowany

PDF created with pdfFactory trial version

www.pdffactory.com

background image

Programownie aplikacji wspó

łbieżnych Jędrzej Ułasiewicz Rozdz 5 str. 11

5.10

Własności modelu

procesów i komunikatów


Wydajność
Model procesu sekwencyjnego posiada wydajne narz

ędzia implementacyjne

(kompilatory itd.). Gdy procesy wykonywane s

ą na różnych procesorach, sprzęt jest

dobrze wykorzystany.

Niezależność od fizycznej struktury maszyny.
Model procesów i komunikatów jest niezale

żny od tego czy procesy wykonywane są

w systemie jedno, wieloprocesorowym czy rozproszonym.

Skalowalność
Model jest niezale

żny od liczby dostępnych procesorów.


Modularność
Problem mo

że być podzielony na tworzone niezależnie moduły (procesy),

komunikuj

ące się poprzez dobrze zdefiniowane interfejsy (komunikaty, kanały).


Determinizm
Program jest deterministyczny gdy takie same sekwencje na wej

ściu, powodują takie

same sekwencje na wyj

ściu. W modelu procesów i komunikatów łatwo osiągnąć

determinizm.


PDF created with pdfFactory trial version

www.pdffactory.com


Wyszukiwarka

Podobne podstrony:
Komunikaty Wstep 9 id 243825 Nieznany
komunikowanie polityczne id 243 Nieznany
KOMUNIKACJA WEWNETRZNA id 24377 Nieznany
gk 01 wstep id 191745 Nieznany
aue wstep id 72298 Nieznany
cwiczenia5 wstep id 124970 Nieznany
AWP wyklad wstep D id 74559 Nieznany
Komunikacja miejska id 243644 Nieznany
Komunikat CBOS id 243807 Nieznany
Komunikacja spoleczna id 243683 Nieznany
komunikacyjne Model 2 id 243805 Nieznany
NoM wstep id 320698 Nieznany
Zloza 2014 wstep id 566869 Nieznany
komunikacja i perswazja id 2434 Nieznany
KOmunikacja sprzedazy id 243716 Nieznany
Komunikacja to id 243720 Nieznany
pdxp wstep id 353063 Nieznany
Mury wstep id 310556 Nieznany
komunikacja wewnetrna id 243774 Nieznany

więcej podobnych podstron