PHP RFC: Add pecl_sync to core

• Version: 1.1
• Date: 2014-09-29
• Author: Guilherme Blanco guilhermeblanco@php.net
• Status: In Draft
• First Published at: http://wiki.php.net/rfc/sync

A discussion whether it is feasible to add sync PECL extension to the core.

When dealing with high volume websites, caching is a common technique used by many to not overload web servers. Considering this scenario, upon a cache expire, you may potentially face cache stampede (aka. cache dogpiling), where multiple requests are trying to write same key at the same time. Not all drivers support antidogpiling natively, leading to errors, notices or even unwanted siblings along the way. Mutexes could drastically reduce the number of write attempts if only one request is writing and others wait or just use non-cache behavior. Worst scenario comes from cache drivers that supports siblings, suck as Riak (https://github.com/php-riak/php_riak), where a high volume web server starts to create on a cache key multiple siblings containing exact same data.

Currently, PHP only offers basic locking concept through the following possibilities:

• File locking emulation
• Semaphore through System V compliant: sem_*
• Relying on pthreads extension

Providing the functionality of pecl_sync with the core distribution.

'sync' extension introduces synchronization objects into PHP. Named and unnamed Mutex, Semaphore, Event, and Reader-Writer objects provide OS-level synchronization on both *NIX (POSIX semaphores required) and Windows platforms.

function saveEntry(Entry $entry) {
    $lock = new SyncMutex($entry->getKey());
 
    if ($lock->lock(0)) {
       // Do expensive saving procedure
 
       $lock->unlock();
    }
 
    // Another process is dealing with save already... =)
}

PHP7, resp. git:master

Classes that would become internal:

• SyncMutex
• SyncSemaphore
• SyncEvent
• SyncReaderWriter

• pecl_sync has not been ported to PHPNG yet.
• Possible class renaming (ie. SyncMutex => Mutex, SyncSemaphore => Semaphore, etc)
• Documentation

A simple yes/no vote with a 50%+1 majority needed for acceptance.

• 1.1
  • Added rationale and code example
• 1.0
  • Original draft