[Python-ideas] Add faster locks to the threading module?
cs at zip.com.au
Wed Jul 21 08:22:27 CEST 2010
On 21Jul2010 02:51, Sturla Molden <sturla at molden.no> wrote:
| Thread synchronization with threading.Lock can be expensive. But
| consider this: Why should the active thread need to aquire a mutex,
| when it already holds one? That would be the GIL.
| Instead of acqiring a lock (and possibly inducing thread swiching
| etc.), it could just deny the other threads access to the GIL for a
| while. The cost of that synchronization method would be completely
| amortized, as check intervals happen anyway.
| The usecase for this "gillock" is about the same as for a spinlock
| C. We want synchronization for a breif period of time, but don't
| want the overhead of aquiring a mutex.
But a spinlock _does_ acquire a mutex, unless I misremember.
It is just that instead of using a more expensive mutex mechanism that
deschedules the caller until available it sits there banging its head
against a very lightweight (not descheduling) mutex until it gets it;
the efficiency is entirely reliant on _all_ users of the spinlock doing
very little inside the located period.
And therein lies one of my two misgivings about this idea: users of this
must be very careful at all times to do Very Little inside the lock.
Just like a spinlock. This seems very easy to misuse.
The other misgiving is one you've already mentioned in passing:
P.S. A gillock working like the ctypes code above is of course very
dangerous. If a C extension releases the GIL while _Py_Ticker is
astronomic, we have a very bad situation... But real code could try
to safeguard against this. E.g. Py_BEGIN_ALLOW_THREADS and
Py_END_ALLOW_THREADS could be defined to do nothing if _Py_Ticker is
above some ridiculous threshold.
Suppose someone goes:
x = fp.read(1)
and the read blocks? It looks like trivial code but I think the I/O
stuff will release the GIL over a read. Now you're not safe any more.
Cameron Simpson <cs at zip.com.au> DoD#743
The ZZR-1100 is not the bike for me, but the day they invent "nerf" roads
and ban radars I'll be the first in line......AMCN
More information about the Python-ideas