Add thread locking to the UWP gamepads dictionary

[squarebananas]

This pull request is to fix a potential thread issue that may occur when a gamepad is disconnected.

WGI.Gamepad.GamepadAdded and WGI.Gamepad.GamepadRemoved are adding and removing gamepads from a different thread to the game tick where PlatformGetState is likely to be called. If the timing was right a disconnected gamepad could be removed from the dictionary while also accessing it for GetState/GetCapabilities.

This can be prevented by adding a lock statement around each use of the gamepads dictionary.

[nkast]

Locking is not necessary if you replace the dictionary and linq operations with an array.
Reading and writing ints to the array is an atomic operation.
My implementation is here.

Of course I don't object if the maintainers chose to merged your commit right way,
your solution is very straight forward.

[squarebananas]

My implementation is here.

I gave that a try and it seems to work fine.

I was thinking the gamepad object shouldn't be used after being removed and your solution could rarely allow WGI.Gamepad.GetCurrentReading to be run after a gamepad has just been disconnected. However it turns out this works and just returns a default WGI.GamepadReading.

If someone lets me know which way to proceed I can amend the PR.

Also with that first call empty workaround I'm only getting an empty list when placing a breakpoint there but not when running normally. Not sure why that is.

[nkast]

Honesty, your PR is fine. There's no reason to postpone a merge.

About the workaround, I have no idea why it's behaving like that but I left it in just in case
it's a weird race thing that could happen every now and then.

About your other comment, I think you are saying that after reading the gamepad in this line
var gamepad = _gamepads[index];
we might receive a GamepadRemoved event for that gamepad.
I'd say that the gamepad had been physically detached before the event had reach our code anyway.
The end result is the same whether we catch the removed event first and return a default state
or call GetCurrentReading() on a removed gamepad.

[squarebananas]

Thanks.

About your other comment, I think you are saying that after reading the gamepad in this line
var gamepad = _gamepads[index];
we might receive a GamepadRemoved event for that gamepad.

Yeah that's it. I was initially thinking that calling GetCurrentReading on a removed gamepad might work like calling Play on a used SoundEffectInstance which can't be reused. After testing this I found GetCurrentReading works even if the gamepad no longer exists in the static WGI.Gamepad.Gamepads list. So I was just confirming that your method works fine.

[mrhelmut]

Fine by me! Thank you!