Защо да използвате shm_open?

Какво е предимството да направите: shm_open последва mmap?
Защо не създадете обикновен файл и след това да прехвърлите това fd към mmap?
Не виждам предимството на shm_open - това са само препратки, са те не?

Чела съм мъжа на цялото семейство. Струва ми се, че тайната е в действието mmaping - типът файл изглежда безсмислен.

Всички указатели ще са добри, особено с отчет за производителност.
Моят контекст е (цикличен презаписваем) буфер (да речем 128MB), който постоянно ще се записва като един процес и постоянно ще се изхвърля от друг.

Като пример: какво не е наред с този open/mmap подход.

РЕДАКТИРАНЕ
За да бъдем точни, едно от следните по-добро ли е от другото:

fd = open("/dev/shm/myshm.file", O_CREAT|O_RDWR, S_IRUSR | S_IWUSR);
mem = mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_SHARED, fd, 0);

vs.

fd = shm_open("/myshm.file", O_RDWR|O_CREATE, S_IRUSR | S_IWUSR);
mem = mmap(...same as before...);

Когато създадох файл с обикновен open под /dev/shm fs и изхвърлих Gig боклук в него, наличната ми памет намаля с 1G, а наличното ми дисково пространство остана същото.
Каква е разликата между двата метода ?


person Trevor    schedule 21.07.2014    source източник
comment
Просто опитайте. писането във файл е може би сто пъти по-бавно.   -  person Jens Gustedt    schedule 22.07.2014


Отговори (3)


Ако отворите и mmap() обикновен файл, данните ще попаднат в този файл.

Ако просто трябва да споделите регион на паметта, без да е необходимо да запазвате данните, което налага допълнителни I/O разходи, използвайте shm_open().

Такава област на паметта би ви позволила също така да съхранявате други видове обекти като мютекси или семафори, които не можете да съхранявате в обикновен файл с mmap() на повечето системи.

person nos    schedule 21.07.2014
comment
Но какво ще стане, ако създам файла под /dev/shm fs? така, отворете (/dev/shm/myshm, w)? Какво е предимството от използването на shm_open? - person Trevor; 22.07.2014
comment
Тогава би било почти същото, ако използвате shm_open или open, но не забравяйте, че това е специфично за Linux. Би било доста безсмислено да се направи, когато съществува стандартен подход. shm_open се грижи да намери /dev/shm, ако е монтиран и на нестандартно място. - person nos; 23.07.2014
comment
Благодаря, че посочихте проблема с преносимостта. Нашият продукт се доставя като виртуална машина на клиенти, така че ние контролираме разпространението, което нашият код изпълнява, така че можем да управляваме това. Това, което ме накара на първо място, беше невъзможността да създавам логически директории под /dev/shm fs. Това е артефакт на shm_open на glibc и не е проблем на fs - така че ще използвам open(). - person Trevor; 23.07.2014
comment
@Trevor, имайте предвид, че според стандарта POSIX: Интерпретацията на символите с наклонена черта, различни от водещата наклонена черта в името, е дефинирана от имплементацията. Защо не се придържате към използването на стандартното API извикване и просто заобиколите ограничения, напр. като използвате долна черта или друг специален знак в името на файла, за да разделите логическите части, вместо да създавате директории под /dev/shm? - person Hristo Iliev; 23.07.2014
comment
Това, което предлагате, наистина е правилно - и аз все още го считам. Въпреки това, например, ако искам да изпълня и inotify в нашата директория под /dev/shm, трябва да прибягна до изпълнение на inotify над /dev/shm - и да бъда изложен на други процеси, регистрирани в това пространство. Само един пример ми идва на ум - person Trevor; 23.07.2014
comment
@nos, може ли shm_open, последвано от mmap, да ви позволи да съхранявате pthread mutex_t, който може да бъде модифициран от функцията pthread_mutexattr_setpshared в Ubuntu Linux 15.10 glibc 2.21? Причината за този въпрос е, че бих искал да използвам pthread_mutex_t за настройка на междупроцесна синхронизация. Благодаря ти. - person Frank; 22.04.2016
comment
@Христо Илиев и Тревър, може ли shm_open, последвано от mmap, да ви позволи да съхранявате pthread mutex_t, който може да бъде модифициран от функцията pthread_mutexattr_setpshared в Ubuntu Linux 15.10 glibc 2.21? Причината за този въпрос е, че бих искал да използвам pthread_mutex_t за настройка на междупроцесна синхронизация. Благодаря ти - person Frank; 22.04.2016
comment
@Frank, да, можеш да го направиш. - person nos; 22.04.2016
comment
@nos, благодаря ти за отговора. Бихте ли могли да погледнете UNIX diff изхода на glibc 2.21 и glibc 2.22 от pthread_mutexattr_setpshared.c, показан в fossies.org/diffs/glibc/2.21_vs_2.22/nptl/ и обяснете защо все още мога да използвам функцията pthread_mutexattr_setpshared.c в Ubuntu Linux 15.10 glibc 2.21 за настройте pthread_mutex_t за извършване на междупроцесна синхронизация. Казаха ми, може би неправилно, че има грешка във функцията pthread_mutexattr_setpshared.c в Ubuntu Linux 15.10 glibc 2.21. Благодаря ти. - person Frank; 22.04.2016

И двете извиквания са по същество еквивалентни в съвременния Linux - първият подход може да се използва за достъп до POSIX споделена памет от езици като go (вижте https://github.com/fabiokung/shm/blob/master/shm_linux.go), където споделената памет на POSIX не е налична първоначално - може да е различно за друга ОС/версия, където 1-ва call ще доведе до създаване на някакъв файл или /dev/shm просто не е наличен и/или евентуално по-бавна производителност. Правилата за сливане на пътеки може също да се развиват от версия на версия на librt

1-ви подход, наречен API за картографирани файлове в паметта (поддържа се в std libs)

2-ро наречено API за споделена памет на POSIX (изисква librt, известен още като libposix на Linux като зависимост. Той вътрешно конструира път и извиква отворено)

person Maxim Sinev    schedule 30.03.2017

След като прочетох източника на shm_open, мога да кажа, че тези два метода са почти еднакви.

връзка: https://code.woboq.org/userspace/glibc/sysdeps/posix/shm_open.c.html

shm_open просто добавя префикс shm_dir, след което извиква нормален open syscall, нищо особено.

person LeeLee    schedule 08.12.2020