txrwlock 1.1.1

Readers/Writer Lock for Twisted

Readers/Writer Lock for Twisted

• Free software: MIT

• Documentation: http://txrwlock.readthedocs.io/en/latest/

• Source: https://github.com/Stibbons/txrwlock

• Presentation: http://www.great-a-blog.co/readerswriter-lock-for-twisted/

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:

from twisted.internet import defer
from txrwlock import TxReadersWriterLock

...

class MySharedObject(object):

    def __init__(self):
        self._readWriteLock = TxReadersWriterLock()

    @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()

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

Setup for development and unit tests

$ make dev

Build source package, binary package and wheel:

make dists

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

Execute unit test:

make test

Execute coverage:

make coverage