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

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

Typy komunikacji ze wzgl

ędu na liczbę odbiorców:

•

Klient – serwer (jeden do jednego)

•

Komunikacja grupowa

W komunikacji klient / serwer komunikaty wymieniane by

ły

pomi

ędzy dwoma procesami. Typ komunikacji jeden do

jednego.

Grupa – zbiór procesów dzia

łających wspólnie w sposób

okre

ślony poprzez system lub użytkownika.

Komunikacja grupowa – jeden proces wysy

ła komunikat

odbierany przez wiele procesów nale

żących do grupy.

PDF created with pdfFactory trial version

www.pdffactory.com

Programownie aplikacji wspó

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

grupa

N

O

N

O

O

O

O

jeden do jednego

jeden do wielu

Z przesy

łaniem komunikatów wiążą się 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)

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

PDF created with pdfFactory trial version

www.pdffactory.com

Programownie aplikacji wspó

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

Przesy

łanie komunikatów realizowane jest przez system

operacyjny.
Funkcje systemu operacyjnego:

•

Zapewnienie transmisji komunikatu pomi

ędzy komputerami i

ukrycie szczegó

łów tej transmisji.

•

Wykrywanie i korygowanie b

łędów transmisji.

•

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

Programownie aplikacji wspó

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

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

Programownie aplikacji wspó

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

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

Programownie aplikacji wspó

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

5.4 Adresowanie

Do adresowania procesu docelowego stosuje si

ę następujące rozwiązania:

Miejsce przeznaczenia

Systemy operacyjne i
środowiska

Niezale

żność

po

łożenia

PID procesu

V, QNX4

Tak

Porty

Mach Chorus, Amoeba

Tak

Gniazda (IP maszyny + numer portu)

Unix

Nie

Grupy procesów

V, Amoeba

Tak

Nazwy symboliczne procesów

QNX4, QNX6

Tak

Obiekty

Cloud, Emerald

Tak

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.

PDF created with pdfFactory trial version

www.pdffactory.com

Programownie aplikacji wspó

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

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)

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

PDF created with pdfFactory trial version

www.pdffactory.com

Programownie aplikacji wspó

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

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)

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

PDF created with pdfFactory trial version

www.pdffactory.com

Programownie aplikacji wspó

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

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

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

Programownie aplikacji wspó

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

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

Programownie aplikacji wspó

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

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