|
Shared Memory
Shared memory allows one or more processes to communicate via memory that appears
in all of their virtual address spaces.
The pages of the virtual memory is referenced by page table entries in each of the
sharing processes' page tables.
It does not have to be at the same address in all of the processes' virtual memory.
As with all System V IPC objects, access to shared memory areas is controlled via
keys and access rights checking.
Once the memory is being shared, there are no checks on how the processes use
it.
They must rely on other mechanisms, for example System V semaphores, to synchronize
access to the memory.

System V IPC Shared Memory
Each newly created shared memory area is represented by a shmid_ds data structure.
These are kept in the shm_segs vector.
The shmid_ds data structure decribes how big the area of shared memory is, how
many processes are using it and information about how that shared memory is mapped into
their address spaces.
It is the creator of the shared memory that controls the access permissions to that
memory and whether its key is public or private.
If it has enough access rights it may also lock the shared memory into physical memory.
Each process that wishes to share the memory must attach to that virtual memory via a
system call.
This creates a new vm_area_struct data structure describing the shared memory
for this process.
The process can choose where in its virtual address space the shared memory goes or
it can let Linux choose a free area large enough.
The new vm_area_struct structure is put into the list of vm_area_struct
pointed at by the shmid_ds.
The vm_next_shared and vm_prev_shared pointers are used to link them together.
The virtual memory is not actually created during the attachment; it happens when the first
process attempts to access it.
The first time that a process accesses one of the pages of the shared virtual memory, a page
fault will occur.
When Linux fixes up that page fault it finds the vm_area_struct data structure
describing it.
This contains pointers to handler routines for this type of shared virtual memory.
The shared memory page fault handling code looks in the list of page table entries for
this shmid_ds to see if one exists for this page of the shared virtual
memory.
If it does not exist, it will allocate a physical page and create a page table entry
for it.
This entry is saved in the current process' page tables and the shmid_ds..
Consequently, when the next process that attempts to access this memory gets a
page fault, the shared memory fault handling code will use this newly created
physical page for that process too.
So, the first process that accesses a page of the shared memory causes it to be
created and thereafter access by the other processes cause that page to be added
into their virtual address spaces.
When processes no longer wish to share the virtual memory, they detach from it.
So long as other processes are still using the memory the detach only affects the
current process.
Its vm_area_struct is removed from the shmid_ds data structure and
deallocated.
The current process's page tables are updated to invalidate the area of virtual
memory that it once shared.
When the last process sharing the memory detaches from it, the pages of the shared
memory current in physical memory are freed, as is the shmid_ds data structure
for this shared memory.
Further complications arise when shared virtual memory is not locked into physical
memory.
In this case the pages of the shared memory may be swapped out to the system's
swap disk during periods of high memory usage.
How shared memory memory is swapped into and out of physical memory is described
in the section on memory management.
|