On Sep 16, 2009, at 10:39 PM, Steven D'Aprano wrote:
On Wed, 16 Sep 2009 22:08:40 -0700, Miles Kaufmann wrote:
On Sep 16, 2009, at 9:33 PM, Steven D'Aprano wrote:
I have two threads, one running min() and the other running max()
over
the same list. I'm getting some mysterious results which I'm having
trouble debugging. Are min() and max() thread-safe, or am I doing
something fundamentally silly by having them walk over the same list
simultaneously?
min() and max() don't release the GIL, so yes, they are safe, and
shouldn't see a list in an inconsistent state (with regard to the
Python
interpreter, but not necessarily to your application). But a
threaded
approach is somewhat silly, since the GIL ensures that they *won't*
walk
over the same list simultaneously (two separate lists, for that
matter).
Perhaps that's true for list contents which are built-ins like ints,
but
with custom objects, I can demonstrate that the two threads operate
simultaneously at least sometimes. Unless I'm misinterpreting what I'm
seeing.
Whoops, sorry. Yes, if you use Python functions (or C functions that
release the GIL) for the object comparison methods, a custom key
function, or the sequence iterator's methods, then the the min()/max()
calls could overlap between threads. If you have additional threads
that could modify the list, you should synchronize access to it; if
any of the earlier-mentioned functions modify the list, you're likely
to get "mysterious" (or at least potentially unexpected) results even
in a single-threaded context.
On Sep 16, 2009, at 10:41 PM, Niklas Norrthon wrote:
For one time sequences like files and generators your code is broken
for obvious reasons.
s/sequence/iterable/
-Miles
--
http://mail.python.org/mailman/listinfo/python-list
