txrwlock 0.4.8

Features

Twisted implementation of a Readers/Writer Lock. This synchronization primitive allows to lock a share depending on two access roles: “reader” which only access to the data without modifying it, and “writer” which may want to change the data in the share.

• Multiple readers can access to the data at the same time. There is no locking at all when only readers require access to the share

• When a write requires access to the share, it prevents any new reader request to fullfil and put these requests into a waiting queue. It will wait for all ongoing reads to finish

• Only one writer can act at the same time

• This Lock is well suited for share with more readers than writer. Write requests must be at least an order of magnitude less often that read requests

This implementation brings this mechanism to the Twisted’s deferred. Please note they are independent with other multithreading RW lock.

For example, a data structure is shared by a different deferreds, triggered on different contexts. Obviously, only one deferred can be writing to the data structure at a time. If more than one was writing, then they could potentially overwrite each other’s data. To prevent this from happening, the writing deferred obtain a “writer” lock in an exclusive manner, meaning that it and only it has access to the data structure. Note that the exclusivity of the access is controlled strictly by voluntary means. The opposite occurs with readers; since reading a data area is a non-destructive operation, any number of concurent deferred can be reading the data.

However, you should protect all parts that will read data in a coherence way. For example, the reading deferred may be confused by reading a part of the data, getting preempted by a writing deferred, and then, when the reading deferred “resumes”, continue reading data, but from a newer “update” of the data. A data inconsistency would then result.

Heavily inspirated by this example.

Usage

An Inlinecallbacks deferred that needs “read” access to a share use the following pattern:

@defer.inlineCallbacks
def aReaderMethod(...):
    try:
        yield rwlocker.readerAcquire()
        # ... any treatment ...
    finally:
        yield rwlocker.readerRelease()

An Inlinecallbacks deferred that needs “write” access to a share uses the following pattern:

@defer.inlineCallbacks
def aWriterMethod(...):
    try:
        yield rwlocker.writerAcquire()
        # ... any treatment ...
    finally:
        yield rwlocker.writerRelease()

Setup for production

Just ensure requirements.txt is installed with pip. This step is not useful is you use txrwlock from a distribution package or a wheel.

$ pip install -r requirements.txt .

Development

Please note the following magical feature of this repository:

• This package use PBR to compute automatically the version number, generate ChangeLog and AUTHORS.

• Deployment to Pypi is automatically made by Travis on successful tag build. Dependencies declared on

• requirements.txt declares the strict minimum of dependencies for external modules that want to use txrwlock. These dependencies are not version frozen.

• For development, unit test, style checks, you need to install requirements-dev.txt as well.

• Travis validates txrwlock on Linux and AppVeyor on Windows

Create a virtualenv:

$ virtualenv venv
$ # virtualenv --python=python3 venv3
$ source venv/bin/activate
$ pip install --upgrade pip  # Force upgrade to latest version of pip

Setup for development and unit tests

$ pip install --upgrade -r requirements.txt -r requirements-dev.txt -e .

Build source package, binary package and wheel:

python setup.py sdist bdist bdist_wheel

These builds automatically generate ChangeLog and AUTHOR files from the git commit history, thanks PBR.

Execute unit test:

trial txrwlock

Execute coverage:

trial --coverage txrwlock