[Python-ideas] Atomic counter / atomic increment

[Guido van Rossum]

The only reason I can think of for wanting this simple class in the stdlib
would be that on GIL-free Python implementations you could replace it with
a lock-free version. But I think we'd probably want to rethink a bunch of
other datastructures to be lock-free, and a 3rd party package on PyPI makes
more sense to me than jumping right into the stdlib.

On Thu, Aug 25, 2016 at 11:10 AM, Ben Hoyt <benhoyt at gmail.com> wrote:

>
> As long as Python uses a GIL to protect C level function
>> calls, you can use an iterator for this:
>>
>> import itertools
>> x = itertools.count()
>> ...
>> mycount = next(x)
>>
>
> Yeah, that's a neat hack -- I saw it recommended on StackOverflow, and saw
> it used in the standard library somewhere. I think that's probably okay in
> the *CPython* stdlib, because it's CPython so you know it has the GIL. But
> this wouldn't work in other Python implementations, would it (IronPython
> and Jython don't have a GIL). Or when itertools.count() is implemented in
> pure Python on some system? Seems like it could blow up in someone's face
> when they're least expecting it. I also think using *iter*tools is a pretty
> non-obvious way to get a thread-safe counter.
>
> -Ben
>
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>



-- 
--Guido van Rossum (python.org/~guido)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160825/1e35be7d/attachment.html>