Operációs rendszerek Processz közti kommunikáció
A mai program • • • • •
Az IPC modell és jellemzői IPC mechanizmusok A Unix üzenetsor A Unix osztott memória Példaprogramok
Vadász
2
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
3
1
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? Vadász
4
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
5
Kifejezett/ki nem fejezett nevek Lehetséges válaszok (másik kérdéskettő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
6
2
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
7
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
8
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
9
3
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
10
Mechanizmusok modelljei Puffer nélküli, aszimmetrikus csatorna Pufferes, FIFO, aszimmetrikus csatorna Pufferes, FILO, aszimmetrikus csatorna Puffer nélküli, szimmetrikus medence
Vadász
11
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
12
4
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
13
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! Vadász
14
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
15
5
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
16
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
17
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
18
6
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
19
ipcs parancs indvd 12> ipcs IPC status from /dev/kmem as of Wed Sep 7 18:11:04 1994 T ID KEY MODE OWNER GROUP Message Queues: q 50 0x0009fbf1 --rw-rw-rwvadasz staff Shared Memory: m 0 0x000009a4 --rw-rw-rwroot sys Semaphores: indvd 13>
Vadász
20
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
21
7
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
22
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
23
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 */ 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
24
8
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
25
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ő.
Vadász
26
Példaprogramok • Nézzük a „szokásos” helyet http://www.iit.uni-miskolc.hu/~vadasz/GEIAL302B/Peldaprogramok/ipc/msg
• Három fájl …
Vadász
27
9
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( ); shmat( ); shmdt( ); shmctl( );
// készítés, beazonosítás // a processz címtartományára csatolás // lecsatolás // kontroll, jellemzők lekérdezése, // beállítása, megszüntetés Vadász
28
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.
Vadász
29
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.
Vadász
30
10
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
31
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
32
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ő). Vadász
33
11
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*/ };
Vadász
34
Példaprogram • Nézzük a „szokásos” helyet http://www.iit.uni-miskolc.hu/~vadasz/GEIAL302B/Peldaprogramok/ipc/shm
Vadász
35
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( )
Vadász
36
12
Operációs rendszerek Processz közti kommunikáció Vége
13
