Relationship between shared memory and files

Ignoring some details there are two low-level SHM APIs available for in Linux.

We have the older (e.g System V IPC vs POSIX IPC) SysV interface using:

ftok
shmctl
shmget
shmat
shmdt

and the newer Posix interface (though Posix seems to standardize the SysV one as well):

shm_open
shm_unlink

When using shm_open() there appears to be a clear 1 to 1 mapping between files and shared memory segments. However if you use shmget() you can relate multiple segments to a single path using, for example:

key1=ftok(path,1);
key2=ftok(path,2);
shmget(key1,...)
shmget(key2,...)

What if anything the relationship between files and segments in this case? The path given to ftok is just a placeholder. I can't see what purpose it serves. If we consider the Unix philosophy as everything is a file why is this not a one to one mapping?

Separate but related question:

Should the SysV interface be considered deprecated?

There is no such suggestion in shm_open or shm_get

I can find only vague suggestions like:

I think the SysV is considered less thread-safe.

Is there any reason why you might prefer the SysV one (or the posix one) in a modern application?

Solution

The path given to ftok is just a placeholder in the "everything is a file" tradition.

After some time considering I would say mmap is a simpler, safer and more effective API. I personally would avoid shmget etc. completely if possible.

It is particularly awkward to clean up after shmget() see:

Linux IPC: shared memory recovery