Qiskit / coheriq / 35805687691

86%

push

github

Acquire the engine lock in enable_engine (#9)

The comment in enable_engine documents the convention that the domain
lock is always acquired first and any engine lock second, and the
docstring of _enable_engine_low_level states that both locks are held
when it runs.  Neither was true: enable_engine acquired only the domain
lock, while _enable_engine_low_level reads and writes engine._state and
reads engine._impl.

This left the engine-state transition unsynchronized against
AccelerationEngine.materialize, which writes _state and _impl under the
engine lock.  Acquire the engine lock so the code matches the documented
convention.

No deadlock is introduced: no code path holds an engine lock while
acquiring a domain lock, so domain-then-engine remains the only nesting
order.  The env-var activation path in _ensure_realized_impl already
releases the domain lock before calling enable_engine, so it does not
re-enter either lock.

The added test observes both locks from inside the critical section and
fails without the accompanying change.

Assisted-by: Claude Opus 5

2 of 2 new or added lines in 1 file covered. (100.0%)

183 of 213 relevant lines covered (85.92%)

0.86 hits per line