rfc:sync

PHP RFC: Add pecl_sync to core

Introduction

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

Rationale

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

Proposal

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.

Example

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... =)
}

Proposed PHP Version(s)

PHP7, resp. git:master

RFC Impact

Classes that would become internal:

  • SyncMutex
  • SyncSemaphore
  • SyncEvent
  • SyncReaderWriter

Open Issues

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

Proposed Voting Choices

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

Changelog

  • 1.1
    • Added rationale and code example
  • 1.0
    • Original draft
rfc/sync.txt · Last modified: 2017/09/22 13:28 by 127.0.0.1