Resolve race-condition in disable_module_accelerator

[galipremsagar]

Description

Fixes: #17775

This PR fixes a race condition that arises when disable_module_accelerator is used in a multi-threaded setting.

Checklist

• I am familiar with the Contributing Guidelines.
• New or existing tests cover these changes.
• The documentation is up to date with these changes.

[bdice]

Looks fine to me.

[mroeschke]

Might be a dumb question Is it possible for self._use_fast_lib to be modified during this yield statement?

[galipremsagar]

Making this move seems to be also bringing back the race-condition.

[wence-]

I don't think this makes sense. Suppose we have two threads, initially use_fast_lib is True.

Now let's run

with disabled():
    some_code()

The idea with the context manager is that inside the block use_fast_lib is False.

However if there are two threads then we can have the following scenario ("time" is increasing downwards)

# Initially use_fast_lib = True
thread-A                                     thread-B

acquire_lock()
saved = use_fast_lib # reads True            acquire_lock() # blocks
use_fast_lib = False                         
release_lock()                                                              
                                             saved = use_fast_lib # reads False
                                             use_fast_lib = False

some_code() # sees use_fast_lib = False
                                             release_lock()                                   

acquire_lock()
use_fast_lib = saved # writes True
release_lock()                            
                                             some_code() # sees use_fast_lib = True
                                             acquire_lock()
                                             use_fast_lib = saved # writes False
                                             release_lock()

So there are two bugs here:

1. On thread-B some_code thinks it is running with use_fast_lib disabled, but in fact is running with use_fast_lib enabled.
2. After thread-B's context manager exits, it restores the saved version of use_fast_lib, which is False. And we end up outside the block with use_fast_lib = False on both threads, whereas it should be True.

[mroeschke]

Nit: Is it ok if we call stack.enter_context(ImportLock()) after this line?

[galipremsagar]

I tried this change too and the race-condition seems to be coming back.

Note: I tried both suggestions separately and together, all three combinations result in branch-25.02 behavior i.e., a race condition.

[galipremsagar]

/merge