Create and open a new object, or open an existing object.
This is analogous to
open(2).
The call returns a file descriptor for use by the other
interfaces listed below.
Obtain a
stat
structure that describes the shared memory object.
Among the information returned by this call are the object's
size
(st_size),
permissions
(st_mode),
owner
(st_uid),
and group
(st_gid).
To change the permissions of a shared memory object.
Versions
POSIX shared memory is supported since Linux 2.4 and glibc 2.2.
Persistence
POSIX shared memory objects have kernel persistence:
a shared memory object will exist until the system is shut down,
or until all processes have unmapped the object and it has been deleted with
shm_unlink(3)
Linking
Programs using the POSIX shared memory API must be compiled with
cc -lrt
to link against the real-time library,
librt.
Accessing shared memory objects via the file system
On Linux, shared memory objects are created in a
(tmpfs)
virtual file system, normally mounted under
/dev/shm.
Since kernel 2.6.19, Linux supports the use of access control lists (ACLs)
to control the permissions of objects in the virtual file system.
CONFORMING TO
POSIX.1-2001.
NOTES
Typically, processes must synchronize their access to a shared
memory object, using, for example, POSIX semaphores.
System V shared memory
(shmget(2),
shmop(2),
etc.) is an older semaphore API.
POSIX shared memory provides a simpler, and better designed interface;
on the other hand POSIX shared memory is somewhat less widely available
(especially on older systems) than System V shared memory.
This page is part of release 3.14 of the Linux
man-pages
project.
A description of the project,
and information about reporting bugs,
can be found at
http://www.kernel.org/doc/man-pages/.
