> The page also mentions a seqlock which looks interesting to me as
> it's fast for few writers with lots of readers.

A seqlock is suitable for consistent views of simple data structures (e.g. a counter in the Linux kernel), but it won't fly for a high-level language like Python.
The problem is that, despite its name, it's not a lock, but it's based on retries, which means that:
- the critical section must be idempotent (no side effect like incrementing a variable, or crediting a bank account :-)
- your critical section is simple enough so that it can tolerate inconsistent views, e.g.:

with seqlock.rlock():
    z = 1/(x-y)

if the writer threads make sure that x!=y when they hold the seqlock, you can still, if you're unlucky, fall at the wrong time and x==y, then you get a nice ZeroDivisionError.

(And yes, you have the same kind of issues with transational memory, as well as others...).


Otherwise, having a rwlock would be a nice addition, but since the GIL serializes everything anyway, this isn't likely to benefit many situations (unless you do I/O, of course), on CPython at least.
That's why it's definitely important to have the equivalent for multiprocessing.

Also, I prefer reader-writer lock because that's how everyone calls it (not only POSIX), and RWLock looks better than SELock (well, at least to me).