* 5.1:
fix merge
fix merge
Remove branch-version (keep them for contracts only)
[HttpClient] relax auth bearer format requirements
[PHPUnitBridge] Silence errors from mkdir()
[DependencyInjection] Preload classes with union types correctly.
[Serializer] fix decoding float XML attributes starting with 0
add missing dutch translations
[TwigBridge] Remove "transchoice" from the code base
Support PHPUnit 8 and PHPUnit 9 in constraint compatibility trait
Add expectDeprecation, expectNotice, expectWarning, and expectError to TestCase polyfill
[String] fix before/after[Last]() returning the empty string instead of the original one on non-match
Add missing exporter function for PHPUnit 7
[Validator] Add missing romanian translations
[String] fix slicing in UnicodeString
[Cache] Use correct expiry in ChainAdapter
do not translate null placeholders or titles
* 5.1:
[Contracts] add branch-aliases for dev-main
[Cache] Make Redis initializers static
[Messenger] Fixed typos in Connection
[CI] Fixed build on AppVeyor
Fix tests typo
[Lock] Reset Key lifetime time before we acquire it
[CI] Silence errors when remove file/dir on test tearDown()
Fix tests
Remove content-type check on toArray methods
Few years ago, we have introduced the Lock component. This is a very nice component, but sometime it is not enough. Sometime you need semaphore.
This is why I'm introducing this new component.
From wikipedia:
> In computer science, a semaphore is a variable or abstract data type used to control access to a common resource by multiple processes in a concurrent system such as a multitasking operating system. A semaphore is simply a variable. This variable is used to solve critical section problems and to achieve process synchronization in the multi processing environment. A trivial semaphore is a plain variable that is changed (for example, incremented or decremented, or toggled) depending on programmer-defined conditions.
This new component is more than a variable. This is an abstraction on top of different storage.
To make a quick comparison with a lock:
* A lock allows only 1 process to access a resource;
* A semaphore allow N process to access a resource.
Basically, a lock is a semaphore where `N = 1`.
PHP exposes some `sem_*` functions like [`sem_acquire`](http://php.net/sem_acquire). This module provides wrappers for the System V IPC family of functions. It includes semaphores, shared memory and inter-process messaging (IPC).
The Lock component has a storage that works with theses functions. It uses it with `N = 1`.
Wikipedia has some [examples](https://en.wikipedia.org/wiki/Semaphore_(programming)#Examples)
But I can add one more commun use case.
If you are building an async system that process user data, you may want to priorise all jobs. You can achieve that by running at maximum N jobs per user at the same time. If the user has more resources, you give him more concurrent jobs (so a bigger `N`).
Thanks to semaphores, it's pretty easy to know if a new job can be run.
I'm not saying the following services are using semaphore, but they may solve the previous problematic with semaphores. Here is some examples:
* services like testing platform where a user can test N projects concurrently (travis, circle, appveyor, insight, ...)
* services that ingest lots of data (newrelic, datadog, blackfire, segment.io, ...))
* services that send email in batch (campaign monitor, mailchimp, ...)
* etc...
To do so, since PHP is mono-threaded, you run M PHP workers. And in each worker, you look for for the next job. When you grab a job, you try to acquires a semaphore. If you got it, you process the job. If not you try another job.
FTR in other language, like Go, there are no need to run M workers, one is enough.
```php
<?php
use Symfony\Component\Lock\LockFactory;
use Symfony\Component\Lock\Store\RedisStore as LockRedisStore;
use Symfony\Component\Semaphore\SemaphoreFactory;
use Symfony\Component\Semaphore\Store\RedisStore;
require __DIR__.'/vendor/autoload.php';
$redis = new Redis();
$redis->connect('172.17.0.2');
// Internally, Semaphore needs a lock
$lock = (new LockFactory(new LockRedisStore($redis)))->createLock('test:lock', 1);
// Create a semaphore:
// * name = test
// * limit = 3 (it means only 3 process are allowed)
// * ttl = 10 seconds : Maximum expected semaphore duration in seconds
$semaphore = (new SemaphoreFactory($lock, new RedisStore($redis)))->createSemaphore('test', 3, 10);
if (!$semaphore->acquire()) {
echo "Could not acquire the semaphore\n";
exit(1);
}
// The semaphore has been acquired
// Do the heavy job
for ($i = 0; $i < 100; ++$i) {
sleep(1);
// Before the expiration, refresh the semaphore if the job is not finished yet
if ($i % 9 === 0) {
$semaphore->refresh();
}
}
// Release it when finished
$semaphore->release();
```
I looked at [packagist](https://packagist.org/?query=semaphore) and:
* most of packages are using a semaphore storage for creating a lock. So there are not relevant here;
* some packages need an async framework to be used (amphp for example);
* the only packages really implementing a semaphore, has a really low code quality and some bugs.
1. I initially copied the Lock component since the external API is quite similar;
1. I simplified it a lot for the current use case;
1. I implemented the RedisStorage according the [redis book](https://redislabs.com/ebook/part-2-core-concepts/chapter-6-application-components-in-redis/6-3-counting-semaphores/;)
1. I forced a TTL on the storage.
