POSIX shared memory __linux of Linux IPC

Introduction: System v Shared Memory and shared file mappings allow unrelated processes to share memory areas for IPC communication. But there are some drawbacks to these two technologies: 1. The System V Shared memory model uses keys and identifiers that are inconsistent with the standard UNIX I/O model's use of filenames and descriptors, which means that using System V shared memory segments requires a whole new set of system calls and commands. 2. Using a shared file map for IPC requires creating a disk file, even if there is no need for persistent storage of shared areas, and in addition to the inconvenience caused by the need to create files, this technology can also bring some file I/O overhead. Because of these deficiencies, POSIX.1B defines a new set of shared memory Api--posix shared memory. Overview

POSIX shared memory enables unrelated processes to share a mapped area without creating a corresponding file map. Linux starts to support POSIX shared memory from the kernel 2.4. SUSv3 does not specify the implementation details of POSIX shared memory, especially the use of a (real or virtual) file system to identify shared memory objects, but many UNIX implementations use a file system to identify shared memory objects. Some UNIX implementations create a shared object name as a file on a special location on a standard filesystem, and Linux uses a dedicated TMPFS file system that is mounted in the/DEV/SHM directory, which has kernel persistence, meaning that the shared memory object it contains is persistent. These objects are lost after the system shuts down, even if no processes currently open it.

Note: The total amount of memory occupied by the POSIX shared memory area on the system is limited to the size of the underlying TMPFS file system, which typically mounts using the default size (such as 256MB) at startup, and if necessary, the root user can use the command Mount-o remount ,size=<num-bytes> the file system again to modify its size.

To use the POSIX shared memory object, you need to do the following: Use the Shm_open () function to open an object that corresponds to the specified name, and the Shm_open () function is similar to the open () system call, which creates a new shared object or opens an existing object. Shm_open () returns a file descriptor that references the object. The file descriptor obtained in the previous step is passed into the mmap () call and specified map_shared in its flags parameter, which maps the shared memory object to the virtual address space of the process. As with other uses of mmap (), once an object is mapped, the file descriptor can be closed without affecting the mapping. It is then possible to keep this file descriptor open so that subsequent fstat () and ftruncate () calls use this file descriptor.

Description
1. The relationship between Shm_open () and mmap () on POSIX shared memory is similar to the relationship between Shmget () and Shmat () on System V shared memory. Using POSIX shared memory objects requires a two-step process (Shm_open () +mmap ()) instead of using a single function to perform two tasks because of historical reasons. When the POSIX committee added this feature, the mmap () call already existed, in fact, the thing to do here is to replace the open () call with a shm_open () call, where the difference is to use Shm_open () without creating a file on a disk-based file system.
2. Because references to shared memory objects are done through file descriptors, you can use a variety of file descriptor system calls that are already defined in UNIX systems without adding new system calls. using shared memory Objects

#include <fcntl.h>      //defines 0_* constants
#include <sys/stat.h>   //Defines mode constants
#include <sys/mman.h>   

//returns file descriptor on success, or-1 on error
int shm_open (const char *na me, int oflag, mode_t mode);

The name parameter identifies the shared memory object to be created or to open. The Oflag parameter is a bitmask that alters the invocation behavior. If the oflag contains no o_creat, then an existing object is opened, and if O_creat is specified, the object is created when the object does not exist. Specifying both O_EXCL and o_creat ensures that the caller is the creator of the object and returns a eexist error if the object already exists. The Oflag parameter also indicates the access mode of the calling process on the shared memory object, which takes the value of O_rdonly or O_RDWR. O_trunc causes the length of the object to be truncated to 0 after a successful opening of an existing shared memory object.

Oflag	function
O_creat	object is created when it does not exist.
O_excl	Creating objects mutually exclusive with O_create
O_rdonly	Open read-only access
O_rdwr	Turn on read and write access
O_trunc	Truncate object length to 0

The mode parameter can take the same bit value as the permission bit value on the file, and as with the open () system call, the permission mask in mode will take a value based on the process umask and, unlike open (), the mode argument is always required when calling Shm_open (). This parameter needs to be specified as 0 when no new object is created.

When a new shared memory object is created, its initial length is set to 0, which means that after creating a new shared memory object, it is usually necessary to call Ftruncate () before calling Mmap () to set the object's size. After Mmap () is called, you may also need to use Ftruncate () to expand or shrink the shared memory object based on your requirements. When you extend a shared memory object, the newly incremented bytes are automatically initialized to 0.

SUSV3 requires POSIX shared memory objects to have at least kernel persistence, that is, they persist until they are shown to be deleted or the system reboots. When you no longer need a shared memory object, you should use Shm_unlink () to delete it.

#include <sys/mman.h>

//returns 0 on success, or-1 on error
int shm_unlink (const char *name);

The Shm_unlink () function deletes the shared memory object specified by name. Deleting a shared memory object does not affect the existing mapping of the object, it remains valid until the corresponding process calls Munmap () or terminates, but prevents subsequent shm_open () calls from opening the object. Once all processes are unmapped, the object is deleted and the contents are lost. Example

HTTPS://GITHUB.COM/GERRYYANG/TLPI/TREE/MASTER/SRC/PSHM Shared Memory API comparison

Todo