Download the PHP package malkusch/lock without Composer

Requirements | Installation | Usage | Implementations | Authors | License

php-lock/lock

This library helps executing critical code in concurrent situations in serialized fashion.

php-lock/lock follows semantic versioning.

Requirements

• PHP 7.4 - 8.4
• Optionally nrk/predis to use the Predis locks.
• Optionally the php-pcntl extension to enable locking with flock() without busy waiting in CLI scripts.
• Optionally flock(), ext-redis, ext-pdo_mysql, ext-pdo_sqlite, ext-pdo_pgsql or ext-memcached can be used as a backend for locks. See examples below.
• If ext-redis is used for locking and is configured to use igbinary for serialization or lzf for compression, additionally ext-igbinary and/or ext-lzf have to be installed.

Installation

Composer

To use this library through composer, run the following terminal command inside your repository's root folder.

Usage

This library uses the namespace Malkusch\Lock.

Mutex

The Malkusch\Lock\Mutex\Mutex interface provides the base API for this library.

Mutex::synchronized()

Malkusch\Lock\Mutex\Mutex::synchronized() executes code exclusively. This method guarantees that the code is only executed by one process at once. Other processes have to wait until the mutex is available. The critical code may throw an exception, which would release the lock as well.

This method returns whatever is returned to the given callable. The return value is not checked, thus it is up to the user to decide if for example the return value false or null should be seen as a failed action.

Example:

Mutex::check()

Malkusch\Lock\Mutex\Mutex::check() sets a callable, which will be executed when Malkusch\Lock\Util\DoubleCheckedLocking::then() is called, and performs a double-checked locking pattern, where it's return value decides if the lock needs to be acquired and the synchronized code to be executed.

See https://en.wikipedia.org/wiki/Double-checked_locking for a more detailed explanation of that feature.

If the check's callable returns false, no lock will be acquired and the synchronized code will not be executed. In this case the Malkusch\Lock\Util\DoubleCheckedLocking::then() method, will also return false to indicate that the check did not pass either before or after acquiring the lock.

In the case where the check's callable returns a value other than false, the Malkusch\Lock\Util\DoubleCheckedLocking::then() method, will try to acquire the lock and on success will perform the check again. Only when the check returns something other than false a second time, the synchronized code callable, which has been passed to then() will be executed. In this case the return value of then() will be what ever the given callable returns and thus up to the user to return false or null to indicate a failed action as this return value will not be checked by the library.

Example:

LockReleaseException::getCode{Exception, Result}()

Mutex implementations based on Malkush\Lock\Mutex\AbstractLockMutex will throw Malkusch\Lock\Exception\LockReleaseException in case of lock release problem, but the synchronized code block will be already executed at this point. In order to read the code result (or an exception thrown there), LockReleaseException provides methods to extract it.

Example:

Implementations

You can choose from one of the provided Malkusch\Lock\Mutex\Mutex interface implementations or create/extend your own implementation.

• FlockMutex
• MemcachedMutex
• RedisMutex
• SemaphoreMutex
• MySQLMutex
• PostgreSQLMutex
• DistributedMutex

FlockMutex

The FlockMutex is a lock implementation based on flock().

Example:

Timeouts are supported as an optional second argument. This uses the ext-pcntl extension if possible or busy waiting if not.

MemcachedMutex

The MemcachedMutex is a spinlock implementation which uses the Memcached extension.

Example:

RedisMutex

The RedisMutex is a lock implementation which supports the phpredis extension or Predis API clients.

Both Redis and Valkey servers are supported.

If used with a cluster of Redis servers, acquiring and releasing locks will continue to function as long as a majority of the servers still works.

Example:

SemaphoreMutex

The SemaphoreMutex is a lock implementation based on Semaphore.

Example:

MySQLMutex

The MySQLMutex uses MySQL's GET_LOCK function.

Both MySQL and MariaDB servers are supported.

It supports timeouts. If the connection to the database server is lost or interrupted, the lock is automatically released.

Note that before MySQL 5.7.5 you cannot use nested locks, any new lock will silently release already held locks. You should probably refrain from using this mutex on MySQL versions < 5.7.5.

Also note that GET_LOCK function is server wide and the MySQL manual suggests you to namespace your locks like dbname.lockname.

PostgreSQLMutex

The PostgreSQLMutex uses PostgreSQL's advisory locking functions.

Named locks are offered. PostgreSQL locking functions require integers but the conversion is handled automatically.

No timeouts are supported. If the connection to the database server is lost or interrupted, the lock is automatically released.

DistributedMutex

The DistributedMutex is the distributed lock implementation of RedLock which supports one or more Malkush\Lock\Mutex\AbstractSpinlockMutex instances.

Example:

Authors

Since year 2015 the development was led by Markus Malkusch, Willem Stuursma-Ruwen and many GitHub contributors.

Currently this library is maintained by Michael Voříšek - GitHub | LinkedIn.

Commercial support is available.

License

This project is free and is licensed under the MIT.