-
Notifications
You must be signed in to change notification settings - Fork 819
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace global allocation mutex with fine-grained concurrency controls. #535
Comments
The biggest issue here is - how to delete safely without accidentally deleting something that is being concurrently allocated. Or "only delete this object if it's equal to this revision/generation" |
Edit: removed idea, as this below is better. |
This can be done by adding something like "Deleting" status and using regular Update: Instead of deleting, callers would set "Deleting" status (via regular Update which resolves race conditions) and GS controller would be the only one to trigger actual deletion for GS in Deleting state. |
BTW. As soon as we remove the mutex, we will see increased contention on Game Server resources. That can be fixed with batching and randomization of GS to allocate (see #536). |
You know what - we already have this functionality, because of the SDK. It's called Good call. I like it 👍 |
I think I can work on this. |
@jkowalski @ilkercelikyilmaz assignment made! |
PR #572 fixes this partially. I will continue on the allocation improvements so we can get rid-off the Allocation Mutex |
…h local cache. Fixes googleforgames#535
Currently there's a global mutex shared between 4 controllers that prevents allocations from happening when there's a deletion of (any) game server going on, regardless of a fleet it's on, etc.
To get decent allocation throughput this mutex should be removed and we should start relying on conditional mutations of GameServer itself to ensure correctness.
The text was updated successfully, but these errors were encountered: