Shared Memory Caching
Sharing memory space between processes in Unix is done either with the BSD methodology or the System V methodology. The BSD methodology uses the mmap() system call to allow separate processes to map the same memory segment into their own address spaces. The PHP semaphore and shmop extensions provide two alternative interfaces to System V shared memory and semaphores.
The System V interprocess communication (IPC) implementation is designed to provide an entire IPC facility. Three facilities are provided: shared memory segments, semaphores, and message queues. For caching data, in this section you use two of the three System V IPC capabilities: shared memory and semaphores. Shared memory provides the cache storage, and semaphores allow you to implement locking on the cache.
Cache size maintenance is particularly necessary when you're using shared memory. Unlike file-based caches or DBM files, shared memory segments cannot be grown dynamically. This means you need to take extra care to ensure that the cache does not overfill. In a C application, you would handle this by storing access information in shared memory and then using that information to perform cache maintenance.
You can do the same in PHP, but it's much less convenient. The problem is the granularity of the shared memory functions. If you use the shm_get_var and shm_put_var functions (from the sysvshm extension), you are easily able to add variables and extract them. However, you are not able to get a list of all elements in the segment, which makes it functionally impossible to iterate over all elements in the cache. Also, if you wanted access statistics on the cache elements, you would have to implement that inside the elements themselves. This makes intelligent cache management close to impossible.
If you use the shmop functions (from the shmop extension), you have a lower-level interface that allows you to read, write, open, and close shared memory segments much as you would a file. This works well for a cache that supports a single element (and is similar to the suggested uses for a flat file), but it buys you very little if you want to store multiple elements per segment. Because PHP handles all memory management for the user, it is quite difficult to implement custom data structures on a segment returned from shmop_open().
Another major issue with using System V IPC is that shared memory is not reference counted. If you attach to a shared memory segment and exit without releasing it, that resource will remain in the system forever. System V resources all come from a global pool, so even an occasional lost segment can cause you to quickly run out of available segments. Even if PHP implemented shared memory segment reference counting for you (which it doesn't), this would still be an issue if PHP or the server it is running on crashed unexpectedly. In a perfect world this would never happen, but occasional segmentation faults are not uncommon in Web servers under load. Therefore, System V shared memory is not a viable caching mechanism.
| 