Az előadás letöltése folymat van. Kérjük, várjon

Az előadás letöltése folymat van. Kérjük, várjon

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

Hasonló előadás


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

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

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

3 Vadász3 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?

4 Vadász4 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?

5 Vadász5 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.

6 Vadász6 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)

7 Vadász7 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.

8 Vadász8 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.

9 Vadász9 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.)

10 Vadász10 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

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

12 Vadász12 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).

13 Vadász13 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);

14 Vadász14 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!

15 Vadász15 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ó)

16 Vadász16 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.

17 Vadász17 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

18 Vadász18 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ó

19 Vadász19 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

20 Vadász20 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 50 0x0009fbf1 --rw-rw-rw- vadasz staff Shared Memory: m 0 0x000009a4 --rw-rw-rw- root sys Semaphores: indvd 13>

21 Vadász21 A rendszerhívások: msgget #include 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.

22 Vadász22 #include … int msgctl(int id, int cmd, struct msqid_ds *buf); Aholidsor belső leírója; cmdIPC_STAT állapot lekérdő, IPC_SETállapot változtató, IPC_RMIDsort törlő parancs (makró). bufa 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ő). A rendszerhívások: msgctl

23 Vadász23 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ó).

24 Vadász24 Részlet az ipc.h fájlból /* ipc.h */ 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 */ longpad[4];/* reserve area */ }; (A kiemeltek változtathatók az IPC_SET paranccsal.) /* Control Commands. */ #defineIPC_RMID10/* remove identifier */ #defineIPC_SET11/* set options */ #defineIPC_STAT12/* get options */

25 Vadász25 A rendszerhívások: msgsnd int msgsnd(int id, struct msgbuf *msgp, size_t size, int msgflg); Ahol ida 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.

26 Vadász26 A rendszerhívások: msgrcv int msgrcv(int id, struct msgbuf *msgp, size_t size, long msgtyp, int msgflg); Ahol ida 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ő.

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

28 Vadász28 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

29 Vadász29 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.

30 Vadász30 A rendszerhívások: shmget #include 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.

31 Vadász31 A rendszerhívások: shmat void *shmat(int id, const void *addr, int flg); Ahol ida belső leíró, addrleképzési cím-specifikáció, flgvé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.

32 Vadász32 A rendszerhívások: shmdt( ) int shmdt(const void *addr); Aholaddr 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.

33 Vadász33 A rendszerhívások: shmctl( ) int shmctl(int id, int cmd, struct shmid_ds *buf); Aholida belső leíró, cmdIPC_STAT az állapot lekérdő parancs, IPC_SET attribútum beállító parancs, IPC_RMID a szegmens törlés parancsa. bufa 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ő).

34 Vadász34 A szegmens attribútumai struct shmid_ds { struct ipc_perm shm_perm; /* hozzáférések */ intshm_segsz;/* szegmens méret (bájt) */ time_tshm_atime; /* utolsó rákapcsolódási idő */ time_tshm_dtime; /* utolsó lekapcsolódási idő */ ushortshm_cpid; /* készitő pid-je */ ushortshm_lpid; /* utolsó használó pid-je */ shortshm_nattch; /* pillanatnyilag rákapcsolódók száma*/ };

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

36 Vadász36 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 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( )

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


Letölteni ppt "Operációs rendszerek Processz közti kommunikáció."

Hasonló előadás


Google Hirdetések