-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
[coop] Synchronization primitive friendliness #2231
Conversation
42c91e1
to
505f0a4
Compare
@lambdageek @kumpera whenever you have time, would you mind reviewing this PR? Thank you! :) |
For some numbers: when running |
9720459
to
816fe45
Compare
What's causing the 10x reduction in transitions? This change should, if anything, increased the number of transitions. |
luhenry@d435639#diff-df675e7de49d2766cf7cbd6956a00699R50 is what reduces the amount of transitions. We could do the same for semaphores, but we would need to add |
Move all the code to mono-mutex.c, so it will be easier to make it coop suspend friendly.
Move all the code to mono-semaphore.c, so it will be easier to make it coop suspend friendly.
This is to separate from the mono_coop_* mutex and semaphores
Instead of having to use MONO_PREPARE_BLOCKING/MONO_TRY_BLOCKING in the user code, we do it directly in this new mutex and semaphore coop API. Using the mono_os_* locking functions should not be the default case, as that could lead to longer than necessary time to suspend, and even in certain cases to deadlocks.
…>initialization_section to coop implementation
cc938b4
to
bf5c534
Compare
Switching to blocking should only be done when actually blocking (ex: mutex lock, sem wait, cond wait, blocking syscalls), and not around a whole section. This means that blocking can only be a leaf state, and we should not switch from blocking to blocking mode again.
bf5c534
to
4666757
Compare
Provided by Tom Hindle in https://bugzilla.xamarin.com/show_bug.cgi?id=2033#c5
[coop] Synchronization primitive friendliness
No description provided.