Processz közti kommunikáció

Az előadások a következő témára: "Processz közti kommunikáció"— Előadás másolata:

1 Processz közti kommunikáció
Operációs rendszerek Processz közti kommunikáció

2 A mai program Az IPC modell és jellemzői IPC mechanizmusok
A Unix üzenetsor A Unix osztott memória Példaprogramok Vadász

3 Inter Process Communication
A független processz modell a valóságban nem létezik Mindig van közöttük kapcsolat, legalább vetélkedés az erőforrásokért Használjuk ki a tudatos együttműködést: legyen IPC Eddig is tárgyaltunk IPC mechanizmusokat A szignálozás is IPC; szinkronizációs céllal, kis információmennyiség átvitellel A környezeti változókon kommunikálhatnak a szülő – gyermek viszonyban lévők (kis információmennyiség) Fájlokon keresztül is lehet (nagy mennyiség, de lassú) Hogy lehetne jó teljesítménnyel (gyorsan, sokat) információkat átadni? Vadász

4 Az általános modell A kommunikációhoz szükséges a
send([kinek, ]uzenet); receive([kitol, ]uzenet); rendszerhívás pár. 4 kérdés feltehető Küldő processz megvárja-e, hogy a fogadó megkapja az üzenetet? Fogadó processz várjon-e kiadott receive() híváson? Küldő meghatározza-e kinek küld? Fogadó meghatározza-e kitől fogad? Ezek generikus rendszerhívások. Vadász

5 Szinkron – aszinkron kommunikáció
Lehetséges válaszok (az első két kérdésre) Blokkolásos küldés Nem blokkolásos küldés (aszinkronitás) Blokkolós fogadáskor Nincs blokkolódás fogadáskor (aszinkronitás) Ha mind a küldés, mind a fogadás blokkolásos, akkor a kommunikáció szinkron. Ha valamelyik (vagy mindkettő) nem blokkolásos, akkor aszinkron. Vadász

6 Kifejezett/ki nem fejezett nevek
Lehetséges válaszok (másik kérdés-kettősre) Kifejezett a kinek: célzott küldés (explicit naming) Elmarad a kinek: üzenetszórásos küldés (broadcasting, implicit naming) Kifejezett a kitől (explicit naming) Elmaradó kitől (implicit naming) Vadász

7 Használatos változatok
A szinkron és kifejezett neveket használó (explicit naming) kommunikáció hasznos, szokásos. Szinkronizációra kiváló. A blokkolásos küldéses üzenetszórás gyakorlatilag nem használatos (nehéz implementáció) Blokkolós fogadás implicit (hiányzó) nevekkel hasznos. Nem blokkolós fogadás implicit nevezésekkel hasznos lenne, de nehezen menedzselhető. Jó megoldás vezet át az indirekt kommunikációs modellhez. Vadász

8 A számosság és az irány A kommunikációban résztvevők száma
A kifejezett neveket használó kommunikáció két processz közötti. Az implicit nevek használat esetén lehet egy-a-többhöz, ill. több-az-egyhez kommunikáció A szimmetria, aszimmetria Egy kommunikációs mechanizmus általában egyirányú (aszimmetrikus), de lehet többirányú (szimmetrikus) is. Vadász

9 A pufferezés, üzenethossz, érték v. hivatkozás
Egy kommunikációs kapcsolatnak lehet zéró, korlátozott vagy végtelen pufferelési kapacitása. Az üzenethosszra lehetnek korlátok. Az üzenetküldés lehet adatküldéses vagy hivatkozásküldéses jellegű. (A hivatkozásküldéses változat magával hozza a közvetett jelleget.) Vadász

10 Primitív mechanizmusok
Egy fajta primitív IPC mechanizmus a csatorna (channel): az üzenet eltűnik a csatornából, ha „kivesszük” (fogadjuk) Lehet közvetlen vagy közvetett is Pufferes változata lehet FIFO vagy FILO jellegű Másik primitív a medence (pool): a kivett üzenet megmarad a medencében (többször is kivehető) Szokásosan közvetett jellegű Pufferes változata is lehet Szokásosan szimmetrikus Vadász

11 Mechanizmusok modelljei
Puffer nélküli, aszimmetrikus csatorna Pufferes, FIFO, aszimmetrikus csatorna Pufferes, FILO, aszimmetrikus csatorna Puffer nélküli, szimmetrikus medence Vadász

12 Közvetlen és közvetett átvitel
Van közvetlen átvitel (direkt kommunikáció), amihez a processzeknek ismerniük kell egymást (többnyire explicit, de lehet implicit ismeret is). Két processz között szokásos. Van közvetett átvitel (indirekt kommunikáció). Ekkor létezik egy közvetítő entitás (üzenetsor, postaláda stb.), amit a kommunikációban résztvevőknek ismerniük kell. A processz nevekre implicit ismeret, a közvetítő entitásra nézve explicit. Többnyire többirányú (szimmetrikus). Vadász

13 Indirekt kommunikáció
Üzenetsor, mailbox stb. objektum alkotja a kapcsolatot. Ez önálló objektum, azonosítható. Ez lehet csatorna vagy medence is Ezt a közvetítő entitást kell ismerni (asszociálni). Szükséges (generikus) rendszerhívások: create(msg-queue); destroy(msg-queue); associate(msg-queue); send(msg-queue, message); receive (msg-queue, message); Vadász

14 A közvetítő kötődése (binding)
Kötődhet processzhez, A “tulajdonos“ terminálódása esetén a közvetítő megszűnik! A többi processznek “használati“ viszonya van. Ez a viszony jelenthet többféle hozzáférést. A “kötődési“ viszony átruházható. A hozzáférési viszonyok beállíthatók. Kötődhet az OS-hez. Itt is van kreátor processz és vannak asszociáló processzek. A közvetítő entitás “túlélheti“ a processzeket. Lehet egy törlő (destroy) processz is. Különböző hozzáférések itt is! Különböztessük meg a kötődési tulajdonosságot (ez a létezhet-e kérdést dönti el) és a hozzáféréseket is szabályozó tulajdonosságot (ez az küldés- fogadási hozzáférhetőséget szabályozhatja). Kérdés: hol találkoztunk már ezzel a kötődési viszonnyal? Ami a létezési kérdéssel foglakozott? Nos, a processzeknél: minden processznek kell legyen szülője kérdésnél. Ha egy processz terminálódott, gyermekeit át kell adja a nagyszülőnek (kell kötődjön valakihez egy processz). Miért? A zombie processz fogalom a válasz: egy processz után, ha az terminálódik, kellhet takarítani, ezt az végeztethetik akihez kötődik … A postaláda kötődésnél van logika az OS-hez kötődésben (ne szűnjön meg a kreátora halálakor, biztonság). Van logika a processzhez kötődésben is: ne kelljen utólagosan „takarítani” . Vadász

15 Kötődés versus hozzáférés
Különböztessük meg a Kötődési tulajdonosságot és a Hozzáféréseket megszabó tulajdonosságot. A kötődési tulajdonosság a „létezhet-e” kérdéskörrel foglalkozik A hozzáféréseket megszabó tulajdonosság itt a „küldhetek-e/fogadhatok-e üzeneteket” kérdéskörrel foglalkozik. Korábbi példa a tulajdonlási viszonyokra (egzisztenciával foglakozó) Vadász

16 IPC mechanizmusok, felsorolás
Szignálozás. Aszinkron, két processz közt aszimmetrikus, közvetlen, puffer nélküli csatorna; gyors, kis információmennyiséget átvivő. A szokásos “environment“-en keresztüli kommunikáció. Aszinkron, két processz közti aszimmetrikus, puffer nélküli medence; gyors, kevés információ átvivő Fájlokon keresztüli kommunikáció. Aszinkron, sok processz közti, többnyire aszimmetrikus, közvetett, medence; lassú, nagy információmennyiséget átvivő. Lehet FIFO csatorna is (a neveztt pipe mechanizmus) A klasszikus üzenetsor (message queue) rendszer. Osztott memórián keresztüli kommunikáció. Szemaforok, mint kommunikációs mechanizmusok. A BSD socket kommunikáció. Remote Procedure Call. Vadász

17 További témáink A Unix üzenetsor (message queue), rendszerhívások, példaprogramok A Unix osztott memória kezelés rendszerhívásai, példaprogram a rendszerhívásokra Vadász

18 A Unix üzenetsor rendszere
Gyors, közepes átvihető információmennyiség. Indirekt FIFO csatorna, OS kötődésű, többirányú, (elvileg) végtelen puffer kapacitású, változó üzenethosszú. A rendszerhívások: msgget() // készítés, azonosítás msgctl() // kontroll, jellemzők lekérdezése, // megszüntetés msgsnd() // üzenet betétel a sorba msgrcv() // üzenet kivétel a sorból Üzenetsor külső azonosítása: kulcs Üzenetsor belső azonosítása: egy változó Vadász

19 Az üzenetsor A processzektől függetlenül létezik, ha készült.
Tulajdonossági és hozzáférési jellemzőiket a fájl tulajdonossági, hozzáférési kategóriák segítségével szabályozzák. Az ipcs paranccsal bizonyos jellemzőit lekérdhetjük. (Az ipcs az osztott memória és a szemafor objektumokról is tájékoztat). Esettanulmányok a …/Peldaprogramok/ipc/msg jegyzékben Vadász

20 ipcs parancs indvd 12> ipcs
IPC status from /dev/kmem as of Wed Sep 7 18:11: T ID KEY MODE OWNER GROUP Message Queues: q x0009fbf1 --rw-rw-rw- vadasz staff Shared Memory: m x000009a4 --rw-rw-rw- root sys Semaphores: indvd 13> Vadász

21 A rendszerhívások: msgget
#include <sys/types.h> #include <sys/ipcs.h> #include <sys/msg.h> int msgget(key_t key, int msgflg); Ahol key (hexa) kulcs a külső azonosításhoz, msgflg készítéskor védelem, hozzáférés beállítás, azonosításkor létezés ellenőrzés, hozzáférés állítás, A visszaadott érték az üzenetsor belső leírója (azonosítója), vagy hibaérték. Vadász

22 A rendszerhívások: msgctl
#include … int msgctl(int id, int cmd, struct msqid_ds *buf); Ahol id sor belső leírója; cmd IPC_STAT állapot lekérdő, IPC_SET állapot változtató, IPC_RMID sort törlő parancs (makró). buf a felhasználói címtartományhoz tartozó állapotleíró struktúra pointere. Ide másolódnak (innen egyes tagok másolódnak) állapot lekérdezéskor, változtatáskor. Törléskor NULL. A visszaadott érték 0 siker esetén, -1 hiba esetén (ekkor az errno nézhető). Vadász

23 msgctl argumentumok: a buf
A struct msqid_ds néhány tagja: struct ipc_perm msg_perm; /* permission-ok */ struct msg *msg_first; /* első üzenet mutatója */ struct msg *msg_last; /* utolsó üzenet mutatója*/ ulong_t msg_qbytes; /* sor max. hossza*/ ulong_t msg_qnum; /* pillanatnyi üzenetszám */ ulong_t msg_cbytes; /* a sor hossza */ pid_t msg_lspid; /* utolsó küldő processz id */ pid_t msg_lrpid; /* utolsó vevő pid */ time_t msg_stime; /* utolsó adás ideje */ time_t msg_rtime; /* utolsó vétel ideje */ stb. ( Az msg_qbytes változtatható). Vadász

24 Részlet az ipc.h fájlból
struct ipc_perm { uid_t uid; /* owner's user id */ gid_t gid; /* owner's group id */ uid_t cuid; /* creator's user id */ gid_t cgid; /* creator's group id */ mode_t mode; /* access modes */ ulong_t seq; /* slot usage sequence number */ key_t key; /* key */ long pad[4]; /* reserve area */ }; (A kiemeltek változtathatók az IPC_SET paranccsal.) /* Control Commands. */ #define IPC_RMID 10 /* remove identifier */ #define IPC_SET 11 /* set options */ #define IPC_STAT 12 /* get options */ Vadász

25 A rendszerhívások: msgsnd
int msgsnd(int id, struct msgbuf *msgp, size_t size, int msgflg); Ahol id a belső leíró, msgp üzenetstruktúra mutató, size üzenet hossz, msgflg flag, aminek itt kicsi a jelentősége. A struct msgbuf { long mtype; /* üzenet típus, pozitív egész */ char *body; /* üzenet teste, lehet más típus is */ } A típus a fogadásnál a üzenet szelektálásra lesz jó. A hossz a test hossza kell legyen. Vadász

26 A rendszerhívások: msgrcv
int msgrcv(int id, struct msgbuf *msgp, size_t size, long msgtyp, int msgflg); Ahol id a belső leíró, msgp üzenetstruktúra mutató, size üzenet hossz a csonkításhoz, msgtyp típus a szelektáláshoz, msgflg flag, ha IPC_NOWAIT, akkor nem vár. Ha msgtyp = 0, akkor az első bármilyen típusú üzenetet veszi. Ha msgtyp > 0, akkor az adott típusú első üzenetet veszi. Ha msgtyp < 0, akkor a legkisebb típusú első üzenetet, ami az |msgtyp|-nél kisebb vagy egyenlő. |msgtyp| abszolút érték Vadász

27 Példaprogramok Nézzük a „szokásos” helyet Három fájl …
Három fájl … Vadász

28 Unix osztott memóriahasználat
Gyors, közepes információtartalmat átvivő Indirekt zérópufferelt medence, többirányú OS kötődésű. Védelme a fájlvédelmi mechanizmusokkal egyező Az érintett rendszerhívások: shmget( ); // készítés, beazonosítás shmat( ); // a processz címtartományára csatolás shmdt( ); // lecsatolás shmctl( ); // kontroll, jellemzők lekérdezése, // beállítása, megszüntetés Vadász

29 Az elgondolás Készítünk (beazonosítunk) adott méretű memória szegmenst. Ezt leképezzük a processz címtartományára (megadjuk, milyen címeken és milyen típusként lássa a processz a szegmens rekeszeit). Rácsatolódunk. Használjuk az adott címekre való hivatkozásokkal a szegmens rekeszeit. Végül lekapcsoljuk a címtartományt, esetleg töröljük a szegmenst. A készítés során megadhatunk „hozzáférési” korlátokat: rwx jellemzőket. A „leképzés” (rákapcsolás, attach) hasonlít a dinamikus memória allokálásra. Az alloc hívásokkal „bővítjük” a címtartományt és a memóriát. A bővített memória valós memóriamenedzselésű rendszereken a heap-ből adódik, virtuális memória menedzselésű rendszerekben pedig virtuális memória „többlet” lesz az eredmény. Itt, az osztott memória mechanizmusnál a „többlet-memórai” az előre készített memória szegmens. Lássuk be: ugyanazon osztott memória objektum rekeszeit (elemeit) az egyik processz más címein láthatja, mint a másik! Horribile dictu: más-más típusú rekeszeket láthatnak az egyes processzek (persze, a felelősség a programozóké!). Vadász

30 A rendszerhívások: shmget
#include <sys/types.h> #include <sys/ipcs.h> #include <sys/shm.h> int shmget(key_t key, int size, int msgflg); Ahol key (hexa) kulcs a külső azonosításhoz, size a szegmens mérete, msgflg készítéskor védelem, hozzáférés beállítás, azonosításkor létezés ellenőrzés, hozzáférés állítás. A visszaadott érték az osztott memória belső leírója (azonosítója), vagy hibaérték. Készít adott méretű szegmenst az adott hozzáfárásekkel, vagy létezőre rácsatlakozik. A size méretet a PAGE_SIZE méret egész számú többszörösére kerekítik. Vadász

31 A rendszerhívások: shmat
void *shmat(int id, const void *addr, int flg); Ahol id a belső leíró, addr leképzési cím-specifikáció, flg védelem átállítás. Ha az addr NULL értékű, a rendszer alkalmas (még nem használt) címtartomány elemeire képez le. Ha az addr nem NULL, akkor (esetleg kerekítéssel) az adott címtől kezdődő tartományra képez le. A visszaadott érték siker esetén a szegmens leképzett címe. Hiba esetén -1 a visszatérési érték. A visszaadott címet adott típusú pointer veheti fel: ezzel a szegmens rekeszeit az adott típusú adatként láthatjuk. Vadász

32 A rendszerhívások: shmdt( )
int shmdt(const void *addr); Ahol addr a rákapcsolt szegmens címe. A visszaadott érték siker esetén a 0, hiba esetén -1. Kifejezett shmdt( ) hívás nélkül processz terminálódása esetén a lekapcsolódás rejtetten megtörténik. Vadász

33 A rendszerhívások: shmctl( )
int shmctl(int id, int cmd, struct shmid_ds *buf); Ahol id a belső leíró, cmd IPC_STAT az állapot lekérdő parancs, IPC_SET attribútum beállító parancs, IPC_RMID a szegmens törlés parancsa. buf a felhasználói címtartományhoz tartozó állapotleíró struktúra pointere. Ide másolódnak (innen egyes tagok másolódnak) állapot lekérdezéskor, beállításkor. Törléskor NULL. A visszaadott érték 0 siker esetén, -1 hiba esetén (ekkor az errno nézhető). Az IPC_SET paranccsal csakis a shm_perm struktúra uid, gid és mode tagjai állíthatók be! Vadász

34 A szegmens attribútumai
struct shmid_ds { struct ipc_perm shm_perm; /* hozzáférések */ int shm_segsz; /* szegmens méret (bájt) */ time_t shm_atime; /* utolsó rákapcsolódási idő */ time_t shm_dtime; /* utolsó lekapcsolódási idő */ ushort shm_cpid; /* készitő pid-je */ ushort shm_lpid; /* utolsó használó pid-je */ short shm_nattch; /* pillanatnyilag rákapcsolódók száma*/ }; Kérdés: mely tagok kapnak értéket az shmat( ) és az shmdt( ) hívás során? Az IPC_SET paranccsal csakis a shm_perm struktúra uid, gid és mode tagjai állíthatók be! Vadász

35 Példaprogram Nézzük a „szokásos” helyet
Vadász

36 POSIX leképzett fájl Lehetséges, hogy egy fájlt (vagy olyan objektumot, melynek leírója van) leképezzünk egy processz címtartományára #include <sys/mman.h> void *mmap(void *addr, size_t len, int prot, int flags, int fd, off_t offset); Nézzenek utána! Leképzés megszüntetés: munmap( ) Ha addr == NULL, akkor a rendszerre bízom, mely címtartományra képezzenek le. len = milyen hosszon történjen a leképzés. prot lehet PROT_READ | PROT_WRITE | PROT_EXEC, vagy PROT_NONE (nincs ekkor hozzáférés) flags lehet MAP_SHARED (ekkor megosztott) vagy MAP_PRIVATE (ekkor privát) közül kötelezően az egyik. Ez ORed lehet MAP_FIXED-del (veszélyes, ekkor az addr pontos cím). fd a nyitott fájl leírója (descriptor). offset többnyire 0, a fájl kezdetétől az eltolás, ahol a címleképzés valóban kezdődik. Visszaadja a leképzés kezdő címét. Vadász

37 Processz közti kommunikáció Vége
Operációs rendszerek Processz közti kommunikáció Vége