Context
Spun off from #2821. When cudaq.make_kernel() is called inside a loop that also dispatches observe_async / sample_async, the MLIR context is accessed from multiple threads without synchronization, producing a bare segfault with no actionable error message.
The workaround (build the kernel before the loop) was confirmed by the reporter, but the failure mode — a silent segfault inside kernel_builder.py → _func_ops_ext.py — is hostile to users.
Reproducer
import cudaq
cudaq.set_target("nvidia", option="mqpu")
def build_kernel():
k, params = cudaq.make_kernel(list[float])
qubits = k.qalloc(5)
for i in range(5):
k.rx(params[i], qubits[i])
return k
# This segfaults because make_kernel is not thread-safe
for i in range(100):
ker = build_kernel() # <-- called inside async dispatch
cudaq.sample_async(ker, [0.1]*5, qpu_id=i % 4)
Expected behavior
Either:
- Preferred: make_kernel() is thread-safe and works correctly when called concurrently, or
- Minimum: A clear RuntimeError is raised (e.g., "Kernel construction is not thread-safe; build kernels before dispatching async work") instead of a segfault.
Additionally
The thread-safety constraint should be documented in the multi-GPU workflows guide and in the make_kernel API docstring.
Environment
Originally reported on CUDA-Q 0.10.0
Workaround confirmed on 0.10.0+
Related
#2821 (original report, being closed with workaround)
Context
Spun off from #2821. When
cudaq.make_kernel()is called inside a loop that also dispatchesobserve_async/sample_async, the MLIR context is accessed from multiple threads without synchronization, producing a bare segfault with no actionable error message.The workaround (build the kernel before the loop) was confirmed by the reporter, but the failure mode — a silent segfault inside
kernel_builder.py→_func_ops_ext.py— is hostile to users.Reproducer
Expected behavior
Either:
Additionally
The thread-safety constraint should be documented in the multi-GPU workflows guide and in the make_kernel API docstring.
Environment
Originally reported on CUDA-Q 0.10.0
Workaround confirmed on 0.10.0+
Related
#2821 (original report, being closed with workaround)