You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I suspect we might want something faster than just locking the iterator in this case. Locking might slow down iteration quite a bit. Will wait for Sam to hear his ideas.
Thanks for the link! I don't think we can do the same thing for the rangeiter_next as it might easily cause it to exceed its range. I have another idea using seqlocks.
I don't think we want to fix this -- the performance trade-off is not worth it. We should instead document that iterators aren't thread-safe -- that they won't be guaranteed to return unique elements if accessed concurrently from multiple threads.
I don't think we want to fix this -- the performance trade-off is not worth it. We should instead document that iterators aren't thread-safe -- that they won't be guaranteed to return unique elements if accessed concurrently from multiple threads.
I think that we can close the issue after some documentation.
@eendebakpt , AFAIK, you are working on several other cases, but if your works are related to thread-safe of iterators, I think that Sam's opinion is more reasonable for me.
I don't think we want to fix this -- the performance trade-off is not worth it. We should instead document that iterators aren't thread-safe -- that they won't be guaranteed to return unique elements if accessed concurrently from multiple threads.
I am worried that not making it thread safe will lead to some very hard to track down bugs. Besides the risk of returning unexpected elements (maybe it is enough to document this, although I am personally not convinced yet), there is also the risks of overflows inside the C code (that will happen for the reversed iteration).
Regardless of the final decision, I will benchmark the enumerate and reversed iterators with and without the critical sections to see what performance trade-off we are talking about.
@colesbury If I understand correctly we want the container iterators to be thread-safe in the sense that iterating using multiple threads will not crash the interpreter, but it is ok to be not thread-safe in the sense that the iterator can return results that would under single-threading be considered a bug. For example when using multiple threads the iteration over enumerate(range(10)) could return (5, 6).
That was very surprising for me as a user! I did read PEP 703 again, and I believe the behavior is correctly described in the section on container thread-safety. Also the documentation update by @corona10 will help. Nevertheless, I am wondering if we can somehow make users more aware of this. For example by providing explicit examples in documentation like https://github.com/python/cpython/blob/main/Doc/howto/free-threading-extensions.rst?
If I understand correctly we want the container iterators to be thread-safe in the sense that iterating using multiple threads will not crash the interpreter, but it is ok to be not thread-safe in the sense that the iterator can return results that would under single-threading be considered a bug
Yes
For example by providing explicit examples in documentation like...
Yes, I agree. I've started working on a free-threading howto for Python.
Activity
Fidget-Spinner commentedon Jun 14, 2024
I suspect we might want something faster than just locking the iterator in this case. Locking might slow down iteration quite a bit. Will wait for Sam to hear his ideas.
Fidget-Spinner commentedon Jun 14, 2024
Btw, the race is rangeiter_next (and all the other iterator protocols) racing with itself. Here's a sample:
rostan-t commentedon Jun 14, 2024
In the section Container Thread-Safety, PEP 703 mentions fast paths for
listiter_nextanddictiter_iternextkey/value/item.Fidget-Spinner commentedon Jun 14, 2024
Thanks for the link! I don't think we can do the same thing for the
rangeiter_nextas it might easily cause it to exceed its range. I have another idea using seqlocks.pythongh-120496: Use CAS approach for rangeiter_next
pythongh-120496: Use CAS approach for rangeiter_next
pythongh-120496: Use Critical section for rangeiter_next
colesbury commentedon Jun 17, 2024
I don't think we want to fix this -- the performance trade-off is not worth it. We should instead document that iterators aren't thread-safe -- that they won't be guaranteed to return unique elements if accessed concurrently from multiple threads.
corona10 commentedon Jun 18, 2024
+1
corona10 commentedon Jun 18, 2024
I think that we can close the issue after some documentation.
@eendebakpt , AFAIK, you are working on several other cases, but if your works are related to thread-safe of iterators, I think that Sam's opinion is more reasonable for me.
pythongh-120496: Add a note about iterator thread-safe
eendebakpt commentedon Jun 18, 2024
I am worried that not making it thread safe will lead to some very hard to track down bugs. Besides the risk of returning unexpected elements (maybe it is enough to document this, although I am personally not convinced yet), there is also the risks of overflows inside the C code (that will happen for the reversed iteration).
Regardless of the final decision, I will benchmark the
enumerateandreversediterators with and without the critical sections to see what performance trade-off we are talking about.gh-120496: Add a note about iterator thread-safe (gh-120685)
pythongh-120496: Add a note about iterator thread-safe (pythongh-120685)
[3.13] gh-120496: Add a note about iterator thread-safe (gh-120685) (#…
pythongh-120496: Add a note about iterator thread-safe (pythongh-120685)
eendebakpt commentedon Jun 23, 2024
@colesbury If I understand correctly we want the container iterators to be thread-safe in the sense that iterating using multiple threads will not crash the interpreter, but it is ok to be not thread-safe in the sense that the iterator can return results that would under single-threading be considered a bug. For example when using multiple threads the iteration over
enumerate(range(10))could return(5, 6).That was very surprising for me as a user! I did read PEP 703 again, and I believe the behavior is correctly described in the section on container thread-safety. Also the documentation update by @corona10 will help. Nevertheless, I am wondering if we can somehow make users more aware of this. For example by providing explicit examples in documentation like https://github.com/python/cpython/blob/main/Doc/howto/free-threading-extensions.rst?
colesbury commentedon Jun 23, 2024
Yes
Yes, I agree. I've started working on a free-threading howto for Python.
pythongh-120496: Add a note about iterator thread-safe (pythongh-120685)
pythongh-120496: Add a note about iterator thread-safe (pythongh-120685)
pythongh-120496: Add a note about iterator thread-safe (pythongh-120685)
dictiter_iternextwith with free-threading build #148873 as a duplicate of this issue