Registry / database / oslo-concurrency

oslo-concurrency

JSON →
library7.5.0pypypi✓ verified 84d ago

The oslo.concurrency library provides utilities for safely running multi-thread and multi-process applications using locking mechanisms, as well as for running external processes. It is a core component of the OpenStack Oslo project, which generally follows a six-month release cadence for major OpenStack releases.

pip install oslo-concurrency
INSTALL
IMPORT
SIG · OSLO-CONCURRENCY
O
oslo-concurrency
databasepythonv7.5.0
Install
4.4s avg
Import
470ms
Disk
45MB
Pass rate
10/ 10
Env Coverage10 / 10
glibc
3.93.13
musl
3.93.13
Install & Compatibility
Where this runs
tested against v7.5.0 · pip install
no network on importno background threads
Install × environment matrix
Each cell = how many times install + import succeeded across repeated harness runs. Partial = flaky.
glibc = Debian/Ubuntu slim · musl = Alpine Linux
musl
py 3.103.920 runs
installs and imports cleanly · install 0.0s · import 0.477s · 41.8MB
glibc
py 3.103.920 runs
installs and imports cleanly · install 4.4s · import 0.464s · 43MB
45MB installed
● package 45MB
Code
Verified usage

Verified import paths — ran on the pinned version, not inferred.

lockutils
from oslo_concurrency import lockutils
processutils
from oslo_concurrency import processutils

This quickstart demonstrates how to use `oslo_concurrency.lockutils.synchronized` for inter-process locking. It configures a `lock_path` and defines a function that will be synchronized across different 'workers'. Note that for actual multi-process execution, you would typically run separate Python processes that each call `my_locked_function`.

import os from oslo_concurrency import lockutils # For inter-process locking, a lock_path must be configured. # For this example, we'll use a temporary directory. # In a real application, this should be a secure, dedicated directory. lock_dir = os.environ.get('OSLO_LOCK_PATH', '/tmp/oslo_locks') os.makedirs(lock_dir, exist_ok=True) # Configure oslo.concurrency to use the lock path # This is typically done via oslo.config in a real OpenStack project, # but we can set it directly for a quick example. lockutils.set_defaults(lock_path=lock_dir) @lockutils.synchronized('my-resource', external=True) def my_locked_function(worker_id): print(f"Worker {worker_id} acquired the lock.") # Simulate some work import time time.sleep(0.5) print(f"Worker {worker_id} released the lock.") if __name__ == '__main__': # Example of calling the locked function from multiple 'processes' # In a real scenario, these would be separate processes. print("Attempting to call my_locked_function from multiple 'workers'...") for i in range(3): my_locked_function(f"SimulatedWorker-{i}") # Clean up the lock directory (optional for demo) try: os.rmdir(lock_dir) except OSError: # Directory might not be empty if locks were created pass
Debug
Known issues
breakingOlder `oslo` libraries, including `oslo.concurrency`, deprecated and then removed the use of the `oslo` namespace package. Direct imports like `from oslo_concurrency import lockutils` are now required instead of older patterns that might have relied on a top-level `oslo` package structure.
fix
Update import statements to directly reference `oslo_concurrency` (e.g., `from oslo_concurrency import lockutils`).
affects: < 5.0.0 (approx), specific to each oslo library's transition.
gotchaWhen using inter-process locks (`external=True` in `lockutils.synchronized`), a `lock_path` *must* be configured. This directory is used to store lock files and needs to be accessible and writable by the processes requiring synchronization. For security, it should ideally only be writable by the user running those processes. If not set, `oslo.concurrency` will raise an error or behave unexpectedly.
fix
Set the `lock_path` via `lockutils.set_defaults(lock_path='/path/to/locks')` or by configuring `oslo_concurrency.lock_path` if using `oslo.config`.
affects: All versions using `external=True` locks.
gotchaWhile `oslo.concurrency` provides tools for safe concurrency, be aware of how other libraries handle concurrency. For example, `oslo.messaging` connections are explicitly noted as *not* concurrency safe and should not be shared between threads/greenthreads for both reading and writing, which can lead to eventlet complaints if not handled with separate connections for different operations.
fix
Carefully review the concurrency safety guarantees of all integrated libraries. For `oslo.messaging`, use separate connection instances for concurrent read and write operations if using eventlet/green threads.
affects: All versions (context-dependent on integration with other libraries).
Errors
Common errors & fixes
ImportError: No module named oslo_concurrency
The `oslo.concurrency` package is not installed in the Python environment, or the environment where the code is being run does not have access to the installed package.
fix
Install the library using pip: `pip install oslo-concurrency`
ProcessExecutionError: Unexpected error while running command. Command: <command_details> Exit code: <N>
This error occurs when `oslo_concurrency.processutils.execute` or `trycmd` attempts to run an external command, and the command exits with a non-zero status code (indicating an error) or produces unexpected output.
fix
Examine the `stdout` and `stderr` attributes of the `ProcessExecutionError` exception for details on why the command failed. Ensure the command syntax is correct, its dependencies are met, and it runs successfully outside of the `oslo-concurrency` context. You can also specify allowed exit codes using the `check_exit_code` parameter in `execute` or `trycmd`.
When using `@lockutils.synchronized('mylock', external=True)` my application fails or does not acquire a lock.
When `external=True` is set for `lockutils.synchronized`, `oslo.concurrency` requires a designated directory for lock files to enable inter-process locking. If `lock_path` is not configured, the external locking mechanism cannot function correctly.
fix
Configure a `lock_path` globally using `lockutils.set_defaults(lock_path='/path/to/lock/files')` before using the decorator, or ensure the `OSLO_LOCK_PATH` environment variable is set. The specified directory must be writable by the user running the processes.
My application hangs or experiences deadlocks when using oslo.concurrency locks with multiprocessing.
While `oslo.concurrency` provides robust locking, deadlocks can still occur due to incorrect usage patterns, such as acquiring locks in inconsistent orders across different processes or threads, or failing to release a lock after an error. Issues with Python's `multiprocessing` library's default 'fork' start method on some systems can also contribute.
fix
Review the lock acquisition and release logic to ensure consistent ordering and proper error handling that guarantees lock release. If using `multiprocessing`, consider setting the start method to 'spawn' or 'forkserver' (e.g., `multiprocessing.set_start_method('spawn', force=True)` at the beginning of your main script) to avoid issues related to inherited resources from the parent process.
Upgrade
Version history
7.5.0latest on PyPI · released May 18, 2026
Audit
Dependencies
fastenersrequiredProvides underlying locking primitives.
oslo.utilsrequiredGeneral utility functions from the Oslo project.
oslo.i18nrequiredInternationalization support from the Oslo project.
oslo.configrequiredConfiguration management from the Oslo project, used for options like `lock_path`.
Agent activity
2 hits · last 30 days
node
2
Resources
oslo-concurrency — pip install oslo-concurrency · libregistry