Are min() and max() thread-safe?

[Miles Kaufmann]

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