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
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
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
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
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
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
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
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
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
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
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