Charles-François Natali added the comment:
> 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).
----------
nosy: +neologix
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue8800>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
