gh-120496: Use CAS approach for rangeiter_next

[corona10]

• Issue: Sequence iterator thread-safety #120496

[Fidget-Spinner]

Thanks for doing this! Do you have any benchmark results on how much the perf impact is? versus say using Py_BEGIN_CRITICAL_SECTION ?

[corona10]

Thanks for doing this! Do you have any benchmark results on how much the perf impact is? versus say using

I will try to prepare :)

[corona10]

@Fidget-Spinner @colesbury

I am not sure this will be a fair benchmark, but it shows different strengths in terms of technique and size of N.

Single thread

import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench iter single",
              stmt="""
data = list(it)
""",
              setup = """
N = 100
it = iter(range(N))
"""
              )

• pyperf compare_to single_base.json single_cas.json
  Benchmark hidden because not significant (1): bench iter single

Mutl thread

import pyperf

runner = pyperf.Runner()
runner.timeit(name="bench iter multi",
              stmt="""
for _ in range(100):
    it = iter(range(N))
    with concurrent.futures.ThreadPoolExecutor() as executor:
        data = list(executor.map(lambda _: next(it), range(N)))
""",
              setup = """
import concurrent.futures
N = 100
"""
              )

• Mean +- std dev: [multi_baseline] 284 ms +- 11 ms -> [multi_cas] 277 ms +- 20 ms: 1.03x faster

[Fidget-Spinner]

Hmmm the perf difference is not that large. That might imply that we should just use critical section for simplicity, and hope that someone on PyPI publishes a "prange()" or something like that.

[corona10]

That might imply that we should just use critical section for simplicity, and hope that someone on PyPI publishes a "prange()" or something like that.

Yeah, I prefer this one.

[eendebakpt]

What if we have a range object with len=1 and many threads simultaneously at this point? The check on len has already been done, so the threads each increment the value of start and we end up with a value for result larger than end.

[corona10]

Maybe fail at _Py_atomic_compare_exchange_long?

[corona10]

Ah.. yes understood what you pointed out.

[corona10]

There will be a slight timing issue. Then yes, let's just use the critical section that @Fidget-Spinner also preferred.

[corona10]

To prepare for the overcommitted issue, we can validate the value of the result by comparing the end value.
But let's just use critical section approach.

[corona10]

See: #120540