Remove the redundant s_populate_mutex and only use
ControllerInterface::m_devices_population_mutex instead to prevent a
deadlock caused by locking them in opposite orders.
The device population functions in the win32 InputBackend previously
locked s_populate_mutex first before calling various functions that
locked m_devices_population_mutex. This normally worked but
ControllerInterface::RefreshDevices locks m_devices_population_mutex
first and then calls HandleWindowChange which then locked
s_populate_mutex, potentially causing the deadlock.
Fix this by using PlatformPopulateDevices to lock
m_devices_population_mutex before running the code that was previously
protected by s_populate_mutex. The functions in question lock
m_devices_population_mutex anyway, so this shouldn't meaningfully
increase contention on the lock.
Reproduction steps:
* Let Dolphin finish startup.
* In Win32.cpp::OnDevicesChanged set a breakpoint on the call to
PlatformPopulateDevices. When the breakpoint is triggered the function
will have locked s_populate_mutex, but since PlatformPopulateDevices
won't have run yet m_devices_population_mutex will still be unlocked.
* Unplug a device from your computer.
* Wait for the breakpoint to trigger. (At this point you can plug the
device back in).
* Freeze the ntdll.dll!TppWorkerThread() that triggered the breakpoint.
* Resume Dolphin and start a game.
* Core::EmuThread will call ControllerInterface::ChangeWindow which
calls RefreshDevices. It locks m_devices_population_mutex, then calls
InputBackend::HandleWindowChange, which tries to lock
s_populate_mutex.
* Unfreeze ntdll.dll!TppWorkerThread().
At this point EmuThread and TppWorkerThread are deadlocked. The UI is
still responsive since the Host thread is unaffected, but trying to stop
the game or close Dolphin normally will fail since EmuThread is unable
to stop.