Translations
Info
All page names need to be in English.
en da  de  fr  it  ja  km  nl  ru  zh

Blueprints/SemaphoreLocking

From TYPO3Wiki
Jump to: navigation, search

<- Back to blueprints overview

Blueprint: Semaphore locking

Proposal Improve semaphore locking in Core as it is the safest and quickest way of locking
Owner/Starter Markus Klein
Participants/Members Helmut Hummel, Alexander Opitz
Status Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn
Current Progress Started, Good Progress, Bad Progress, Stalled, Review Needed, Done
Topic for Gerrit locking

Target Versions/Milestones

  • Started during TYPO3 CMS 6.2 development

Goals / Motivation

Currently TYPO3 CMS only implements (and uses by default) only some basic, rather unreliable and slow locking mechanisms. Support for "real", operating system based, process locking is available with the implementation of semaphore locking. Unfortunately the PHP library is only available on unix-based OSs, nevertheless it makes sense to use it, if it is available.

As described in #40420 semaphore locking currently has the problem that, the semaphore is removed immediately after being released. This causes some PHP warnings.

Concept

The issue described above could be tackled by implementing a quite complicated synchronization mechanism of semaphores and shared memory to properly free all resources once they're unused.

Since access to most of the semaphores repeats frequently, it does not make much sense to deallocate them all the time and allocate them again. A comment on php.net also suggests to simply leave them in the memory and limit the amount of different semaphore ids.

Implementation Details

I propose a middle way. Not removing a semaphore at all seems a bit too risky for me. I would move the sem_remove() call to the destructor of the class, hence removing the semaphore latest possible. Moreover I'd would add PHP warning suppression (@) to the sem_acquire() call. In current 6.2 code, an exception is thrown if the lock can't be acquired. I'd suggest to change this code and instead trying to reallocate the semaphore in this situation and do the acquisition again; all in a loop.

Risks

Without bounding the loop it can happen in a very rare situation/constellation that the process stalls here. PHP maximum_execution_time will stop the process some time.

Issues and reviews

Bug report about semaphore issue

Dependencies upon other Blueprints

External links for clarification of technologies