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