-
Notifications
You must be signed in to change notification settings - Fork 5k
Mono: ManualResetEventSlim.Wait() unexpectedly returns without blocking #115178
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
Comments
Tagging subscribers to this area: @mangod9 |
@lateralusX Can you help analyze this problem? |
Thanks for detailed repro and investigation. I will take a look (need to finish some other things first). Wait can return false and on Mono we support alertable waits that could be interrupted and return false, but in case void Wait is called, it doesn't handle that support and assume it will never return false, but currently implementation uses the same underlying API that will handle interrupts/alerts and return false in that case. Possible to run the repro with a custom build runtime and set LOCK_DEBUG? That will create a bunch of debugging around monitor locking and if we hit case of it to return false from wait, we will see what scenario we hit. |
I have dump the LOCK_DEBUG, but I can't kown why it return false the full log add below: |
Thanks, I would expect some more logging from,
and then unless lock is not owned (that shouldn't be the case ), that should not be the case it should at least log:
but none of that logging is present in the file. I will run this later this week and see if I can get a local repro. If you can figure out why we don't get additional logging or add asserts into failures when mono_monitor_wait to get hard failures if we hit those scenarios it would be great. |
Yes, it's a bit strange, I'll continue to look at it today
|
Issue Description
When using
ManualResetEventSlim.Wait()
to synchronize multi-threaded task execution, I've discovered a critical issue in the Mono environment: under high CPU load conditions, theWait()
method sometimes returns immediately without blocking, even though the associated event has not been set. This causes thread synchronization mechanisms to fail and leads to task execution errors.Test Code
Steps to Reproduce
TestTaskScheduler
class and callExec()
method on each frame_TaskCount > 0
,_MainThreadResetEvent.Wait()
returns abnormallyError Symptoms
When the issue occurs, the main thread returns from the Wait state without blocking, even though tasks in other threads are not completed, triggering the following exception:
Analysis
Through debugging, I've found:
_MainThreadResetEvent.Wait()
, even though the event has not been set (confirmed by state check)_TaskCount
is not 0 because tasks have not all completedEnvironment Information
Expected Behavior
According to documentation and behavior in CoreCLR,
ManualResetEventSlim.Wait()
should block the calling thread until the event is set, unless using an overload with timeout parameters.The text was updated successfully, but these errors were encountered: