This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author neologix
Recipients Sebastian.Noack, asvetlov, christian.heimes, jyasskin, kristjan.jonsson, mklauber, neologix, pitrou, sbt
Date 2012-10-01.14:44:06
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
> 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).
Date User Action Args
2012-10-01 14:44:07neologixsetrecipients: + neologix, pitrou, kristjan.jonsson, christian.heimes, jyasskin, asvetlov, sbt, mklauber, Sebastian.Noack
2012-10-01 14:44:06neologixsetmessageid: <>
2012-10-01 14:44:06neologixlinkissue8800 messages
2012-10-01 14:44:06neologixcreate