CODEWITHSUNDEEP
clinuxbuffershared-memorymmap
Trevor
Trevor

Reputation: 1988

Why use shm_open?

What's the advantage of doing: shm_open followed a mmap?
Why not create a regular file, and then pass that fd to mmap?
I can't see the advantage of shm_open - these are just references, are they not?

I've read the man of the whole family. It seems to me, that the "secret" is in the mmaping action - the file "type" seems to be meaningless.

Any pointers will be good, especially with performance account.
My context is a (cyclic over-writable) buffer (say 128MB) that will be constantly written to be one process, and constantly dumped from by another.

As an example: what's wrong with this open/mmap approach.

EDIT
To be precise, is one of the following better than the other:

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...);

When I created a file with regular open under the /dev/shm fs, and dumped a Gig of garbage to it, my available memory went down by 1G, and my avaiable disk space remained the same.
What's the difference between the two methods?

Upvotes: 37

Views: 26553

Answers (4)

Lucian Wischik
Lucian Wischik

Reputation: 2336

It's true that mmap(fopen(/dev/shm)) and shm_open are identical on linux.

They're different on mac simply because /dev/shm doesn't exist on mac!

On mac you could try doing mmap(fopen(some_other_dir)), but then you'd get into struggles to figure out whether some_other_dir will also be on a RAM-backed filesystem, hence whether it will be as performance as shm_open.

Upvotes: 0

LeeLee
LeeLee

Reputation: 178

After reading the source of shm_open, I can say those two methods are almost the same.

link: https://code.woboq.org/userspace/glibc/sysdeps/posix/shm_open.c.html

shm_open just adds shm_dir prefix then invokes normal open syscall, nothing special.

Upvotes: 8

Maxim Sinev
Maxim Sinev

Reputation: 171

Both calls are essentially equivalent on modern Linux - 1st approach could be used to access POSIX shared memory from languages like go (see https://github.com/fabiokung/shm/blob/master/shm_linux.go) where POSIX shared memory not natively available - it might be different for other OS/version where 1st call would lead to some file creation or /dev/shm just not available and/or possibly slower performance. Rules of path merging might also be evolving from version to version of librt

1st approach called memory mapped files API (supported in std libs)

2nd called POSIX shared memory API (requires librt aka libposix on Linux as dependence It's internally constructs path and calls open)

Upvotes: 3

nos
nos

Reputation: 229088

If you open and mmap() a regular file, data will end up in that file.

If you just need to share a memory region, without the need to persist the data, which incurs extra I/O overhead, use shm_open().

Such a memory region would also allow you to store other kinds of objects such as mutexes or semaphores, which you can't store in a mmap()'ed regular file on most systems.

Upvotes: 36

Related Questions