What type of memory objects does `shm_open` use?

Usually, shared memory is implemented using portions of On-Disk files mapped to processes address spaces. Whenever a memory access occurs on the shared region, the filesystem is involved to write changes on the disk which is a great overhead.

Typically, a call to fopen() returns a file descriptor which is passed to mmap() to create the file’s memory map. shm_open, apparently, works in the same way. It returns a file descriptor which can even be used with regular file operations (e.g ftruncate, ftell, fseek …etc). We do specify a string as a parameter to shm_open but unlike fopen(), it is not a name of a real file on the visible filesystem (mounted HDD, Flash drives, SSD … etc). The same string name can be used by totally unrelated processes to map the same region into their address spaces.

So, what is the string parameter passed to shm_open & what does shm_open creates/opens ? Is it a file on some temporary filesystem (/tmp) which is eventually used by many processes to create the shared region (Well, i think it has to be some kind of files since it returns a file descriptor) ? Or is it some kind of a mysterious and hidden filesystem backed by the kernel ?

People say shm_open is faster then fopen because no disk operations are involved so the theory i suggest is that the kernel uses an invisible RAM-based filesystem to implement shared memory with shm_open !

Answer

Usually, shared memory is implemented using portions of On-Disk files mapped to processes address spaces. Whenever a memory access occurs on the shared region, the filesystem is involved to write changes on the disk which is a great overhead.

That seems rather presumptuous, and not entirely correct. Substantially all machines that implement shared memory regions (in the IPC sense) have virtual memory units by which they support the feature. There may or may not be any persistent storage backing any particular shared memory segment, or any part of it. Only the part, if any, that is paged out needs to be backed by such storage.

shm_open, apparently, works in the same way. It returns a file descriptor which can even be used with regular file operations (e.g ftruncate, ftell, fseek …etc).

That shm_open() has an interface modeled on that of open(), and that it returns a file descriptor that can meaningfully be used with certain general-purpose I/O function, do not imply that shm_open() “works in the same way” in any broader sense. Pretty much all system resources are represented to processes as files. This affords a simpler overall system interface, but it does not imply any commonality of the underlying resources beyond the fact that they can be manipulated via the same functions — to the extent that indeed they can be.

So, what is the string parameter passed to shm_open & what does shm_open creates/opens ?

The parameter is a string identifying the shared memory segment. You already knew that, but you seem to think there’s more to it than that. There isn’t, at least not at the level (POSIX) at which the shm_open interface is specified. The identifier is meaningful primarily to the kernel. Different implementations handle the details differently.

Is it a file on some temporary filesystem (/tmp) which is eventually used by many processes to create the shared region

Could be, but probably isn’t. Any filesystem interface provided for it is likely (but not certain) to be a virtual filesystem, not actual, accessible files on disk. Persistent storage, if used, is likely to be provided out of the system’s swap space.

(Well, i think it has to be some kind of files since it returns a file descriptor) ?

Such a conclusion is unwarranted. Sockets and pipes are represented via file descriptors, too, but they don’t have corresponding accessible files.

Or is it some kind of a mysterious and hidden filesystem backed by the kernel ?

That’s probably a better conception, though again, there might not be any persistent storage at all. To the extent that there is any, however, it is likely to be part of the system’s swap space, which is not all that mysterious.