Assessing Bytearray Thread Safety

Under free-threaded CPython (PEP 703, no-GIL builds), individual bytearray method calls are atomic (thread-safe against corruption), but sequences of operations are not atomic. Any code that reads-then-writes, or relies on invariants holding across multiple statements, needs an explicit threading.Lock.

Python
import threading

buf = bytearray(1024)
lock = threading.Lock()

# UNSAFE under free-threading: check-then-act race
if len(buf) > 0:
    buf[0] = 42          # buf could have been resized/cleared by another thread

# SAFE: single atomic call
buf.append(1)             # atomic, no lock needed

# SAFE: compound operation needs a lock
with lock:
    if len(buf) > 0:
        buf[0] = 42

Progress:

• Identify every bytearray instance shared across threads
• Classify each access as single-operation vs. compound (multi-statement)
• For single operations (single method call, single subscript get/set, append, extend, slice assignment as one statement), no lock needed — CPython guarantees the operation itself won't corrupt internal state
• For compound operations (read-modify-write, length-check-then-index, iterate-while-mutating, buffer resize interacting with a memoryview), add a threading.Lock or threading.RLock around the whole sequence
• Pay special attention to memoryview objects backed by a bytearray — resizing the bytearray while a memoryview is exported is unsafe and can raise BufferError or, if not guarded, race
• Verify on the standard GIL build too — locks are correct there and add negligible overhead, so code should be written lock-safe regardless of build
• Test with PYTHON_GIL=0 (or a free-threaded build) using stress loops (many threads hammering the same bytearray) to surface races that only appear without the GIL

Example 1: Input:

Python
counter_buf = bytearray(8)

def increment():
    val = int.from_bytes(counter_buf, "little")
    val += 1
    counter_buf[:] = val.to_bytes(8, "little")

Output: Unsafe — this is a classic read-modify-write race. Two threads can read the same val before either writes back, losing an increment. Fix:

Python
lock = threading.Lock()

def increment():
    with lock:
        val = int.from_bytes(counter_buf, "little")
        val += 1
        counter_buf[:] = val.to_bytes(8, "little")

Example 2: Input:

Python
log_buf = bytearray()

def append_entry(data: bytes):
    log_buf.extend(data)

Output: Safe as-is. extend is a single atomic method call; free-threaded CPython guarantees the internal buffer state stays consistent even with concurrent callers. No lock required (though ordering of entries across threads is still nondeterministic — add a lock only if ordering matters, not for safety).

Example 3: Input:

Python
data = bytearray(range(256))
mv = memoryview(data)

def resize():
    data.extend(b"\x00" * 100)   # thread A

def read():
    print(mv[0])                  # thread B

Output: Unsafe. Resizing a bytearray while a memoryview exports it is undefined/racy territory even beyond normal thread-safety — CPython may raise BufferError on the resize if the memoryview is still exported, and concurrent access patterns are unreliable. Guard both the resize and any memoryview-based access with the same lock, or avoid holding long-lived memoryviews over bytearrays that are concurrently resized.