Sdileni pameti mmap() a shmget()

Michal Dobes dobes na tes.eu
Úterý Květen 6 16:59:28 CEST 2008


Dalibor Straka napsal(a):
> Ahoj vsichni,
> 
> z pohledu programatora je mi jedno, jestli pouziji mmap() nebo shmget().

A to ještě v případě mmap() mám rovnou několik možností, jak to udělat.
Ať již sdílená pamět dle posix přes shm_open(), případně klasický
mmap() nad soubor nebo podepřený anonymní pamětí, ať již dle SVR
(open() nad /dev/zero) nebo BSD zvyklostí (mmap() s MAP_ANON a fd=-1).
:-))

> Je v tom nejaky zasadni rozdil? (Kompatibilita, zastaralost, funkcni
> nevyhody, ...). Budu pouzivat i synchronizacni primitiva semafory mozna
> i zpravy coz spise nahrava shm. Prepisuji vlaknovou aplikaci.

Semafory a fronty zpráv existují nejen dle System V, ale i dle POSIXu.
Co z toho použít je otázka. Pokud přepisuji vícevlákno na samostatné
procesy, tak bych prvně zvážil, zda ponechám semafory a spol vláknové
(čili mutex, cond) a jen je použiji uvnitř sdílené paměti nebo budu
používat semafory a spol z IPC. Pak asi záleží na tom, jaké mám
priority.
Posixovské prostředky mi vycházely trošku míň podporované (nebo jen
částečně, třeba někde jen anonymní semafory, ale už ne pojmenované
atd). Pokud aplikace musí běžet na nejrůznějších obskurních systémech,
tak bych spíše šel po System V IPC. To mi fungovalo snad všude.
Na druhou stranu semafory dle Posixu mi vycházeli obvykle o něco
rychlejší, bylo kolem toho míň systémové omáčky. Ale pokud neočekávám
milióny zamykání za sekundu, tak bych se tím netrápil. Jiný plus pro
semafory dle System V může být UNDO funkce, kdy po chcípnutí procesu,
co drží semafor, dojde k jeho automatickému odemčení, což může bránit,
aby při nenadálém kolapsu jednoho procesu to chcíplo celé. Zase SysV
semafory působí hodně lidem větší potíže, hodně to umí a je náročnější
je zvládnout, posixovské jsou vůči tomu pohoda (ale umí o dost míň).
Pokud bych musel míchat semafory do obsluhy signálů, tak jediný
korektně přípustný je posixovský semafor, pro sem_post() mám
garantováno, že bude async/signal bezpečný, pro semop() to nemám.
U SysV prostředků občas bývá problém, že když to aplikace po sobě
korektně nezavírá, tak zůstává bordel, který může pak bránit vytvořit
nové další prostředky. U posixovských to se stávalo trošku méně často.
Ale je pravda, že záleží na tom, jak mám pro jednotlivé dané limity
(ať již v /proc/sys/kernel/ pro SysV nebo /dev/shm/ pro Posixovské).
Fronty zpráv je také dilema. SysV fronta zpráv je taková přímočařejší,
dá se v tom zblbnout míň věcí. Posixová zase toho umí víc a hlavně
se v ní dá hezky řešit obsluha a čekání na víc věcí, což u SysV se dělá
přenositelně blbě (leda přes další proces a signalizaci po fifo, pokud
vynechám některé specifické rozšíření).
U posixových to můžu hezky navázat třeba na sigevent přes mq_notify().
Samozřejmě můžu všechno hezky namíchat dohromady, od každého použít
něco, ale vyznat se pak v tom po letech...

M.








Další informace o konferenci Linux