make memoryview thread safe in free-threading

[kumaraditya303]

memoryview is currently not safe against free-threading especially concurrent releasing the memoryviews. This issue track work to make it thread safe.

This is a follow-up to #127412 (review).

Linked PRs

• gh-127716: Fix data race in memoryview.release() #154770
• gh-127716: make memoryview thread-safe in free-threaded build #156248

[picnixz]

Do you think it should be a feature (main only) or a bug fix (3.13+)?

[kumaraditya303]

For now I'll target main, if it doesn't need too many changes it may be backported.

[picnixz]

Ok. I'll apply the labels after we decided whether we should backport it or not.

[ZeroIntensity]

FWIW, we typically do backport thread safety fixes to 3.13. We should probably merge gh-127412 before putting up anything new to prevent conflicts.

[devdanzin]

A concrete, crashing reproducer for the "concurrent releasing" part of this issue. On a free-threaded build, several threads calling memoryview.release() on views of one shared buffer (interleaved with reads of a view) underflow the non-atomic export counters and abort.

import threading
buf = bytearray(64)
cell = [memoryview(buf)]
NT = 8
ITERS = 40000

def worker(w):
    for _ in range(ITERS):
        mv = cell[0]
        try:
            if w % 2 == 0:
                mv.release()
                cell[0] = memoryview(buf)
            else:
                _ = mv.readonly
                _ = mv[0]
        except Exception:
            pass

ts = [threading.Thread(target=worker, args=(w,)) for w in range(NT)]
for t in ts: t.start()
for t in ts: t.join()

On a free-threaded debug build (PYTHON_GIL=0) this aborts on essentially every run. The exact assertion that fires depends on the build/scheduling — both are the same root cause, a non-atomic export counter driven below its invariant by concurrent release():

• Debug build with ASan — the memoryview's own mbuf->exports:

  Objects/memoryobject.c:1116: void _memory_release(PyMemoryViewObject *):
      Assertion `self->mbuf->exports > 0' failed.
  

  _memory_release (memoryobject.c:1115) decrements self->mbuf->exports non-atomically, so
  concurrent releases drive it to/below zero.

• Plain debug build (no ASan) — the exporter bytearray's ob_exports:

  Objects/bytearrayobject.c:89: void bytearray_releasebuffer(PyObject *, Py_buffer *):
      Assertion `obj->ob_exports >= 0' failed.
  

  the release path double-decrements the exporter's export count (also non-atomic), so it goes negative.

Both reproduce 5/5 here. Under TSan the same race shows up as data-race stanzas pairing the release side against the read side, e.g. _memory_release / mbuf_release vs memory_readonly_get / memory_item / memory_subscript — and the read of a concurrently-released view is also a use-after-release angle.

This is the release side of the exports counter, which looks still-open under this issue — distinct from the memoryview.hex exports race that was fixed (gh-149858 / item 132 of #149816) and the earlier ->exports fix in gh-127085 (#127412) that this issue is the follow-up to.

Found with fusil's --tsan mode; reduced and drafted with AI assistance (Claude Code), verified by hand on free-threaded debug / ASan / TSan builds of main (3.16.0a0).