Message171721
> 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:07 | neologix | set | recipients:
+ neologix, pitrou, kristjan.jonsson, christian.heimes, jyasskin, asvetlov, sbt, mklauber, Sebastian.Noack |
2012-10-01 14:44:06 | neologix | set | messageid: <1349102646.99.0.453775395606.issue8800@psf.upfronthosting.co.za> |
2012-10-01 14:44:06 | neologix | link | issue8800 messages |
2012-10-01 14:44:06 | neologix | create | |
|