StructuredWorkflowLocks
Contents
Rationale
Locks (and semaphores) are a critical component of most typical applications and especially so for structuring workflows in a manner that allows the entity applying said workflow to ensure that said entity is the only single entity working on said workflow and its associated resources (unless said workflow is a read-only workflow where only a set of read-writer lock/s may be required). Ensuring correct locking and correct locking order is typically a very difficult component of creating reliable and fault tolerant workflows but are absolutely necessary to ensure consistent workflow operations (for example, knowing that some 2 workflow are not modifying a the same resource at the same time). This is especially relevant & important in large scale distributed systems such as OpenStack which have many concurrent workflows being processed at the same time by many varying entities (nova, cinder, quantum for example).
Requirements
Since different workflows will need different ['mutex', 'semaphore'] types there needs to be built-in flexibility of the providing solution that allows said developers using said solution to provide a set of desired requirements and get back a ['mutex', 'semaphore'] that will match (or closely match) there desired requirements.
Oslo requirements (WIP)
- Across-process lock using the local filesystem
Ironic requirements (WIP)
- Exclusive when distributed across hosts (only one host can get it)
- Shared and exclusive between threads (only one gets exclusive, other threads may take shared lock)
- Reference from the lock to all holders
Relevant Links
The CAP theorem provides upper bounds on the abilities that solutions can provide.
