Зачем использовать shm_open?

Какое преимущество: shm_open следует за mmap?
Почему бы не создать обычный файл, а затем передать это fd в mmap?
Я не вижу преимущества shm_open - это просто ссылки, не так ли?

Я прочитал человека всей семьи. Мне кажется, что "секрет" находится в действии mmaping - файл "type" кажется бессмысленным.

Любые указатели будут хорошими, особенно с учетной записью производительности.
Мой контекст - это (циклический перезаписываемый) буфер (скажем, 128 МБ), который будет постоянно записываться как один процесс и постоянно сбрасываться другим.

В качестве примера: что случилось с этим открытым /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); против
fd = shm_open("/myshm.file", O_RDWR|O_CREATE, S_IRUSR | S_IWUSR); mem = mmap(...same as before...);
Когда я создал файл с регулярным open под /dev/shm fs и сбросил на него Gig мусора, моя доступная память опустилась на 1G, и мое доступное дисковое пространство оставалось прежним.
Какая разница между двумя методами?

Ответ 1

Если вы открываете и mmap() обычный файл, данные будут попадать в этот файл.

Если вам просто нужно обмениваться областью памяти, без необходимости сохранять данные, что приводит к дополнительным служебным нагрузкам ввода-вывода, используйте shm_open().

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

Ответ 2

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

1-й подход, называемый API-интерфейсом с отображением памяти (поддерживается в std-библиотеках)

2-й называется API общей памяти POSIX (требуется librt aka libposix для Linux как зависимость Он внутренне конструирует путь и вызывает открытый)