-
Notifications
You must be signed in to change notification settings - Fork 5.3k
Move CoreCLR over to the managed wait subsystem #117788
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
base: main
Are you sure you want to change the base?
Conversation
|
Tagging subscribers to this area: @mangod9 |
25446d0 to
63dc9af
Compare
06de3b2 to
63a1aa6
Compare
src/libraries/System.Private.CoreLib/src/System/Threading/LowLevelLifoSemaphore.Unix.cs
Outdated
Show resolved
Hide resolved
63a1aa6 to
2b610bf
Compare
src/coreclr/System.Private.CoreLib/src/System/Threading/Thread.CoreCLR.cs
Outdated
Show resolved
Hide resolved
src/libraries/Common/src/Interop/Unix/System.Native/Interop.GetPageSize.cs
Outdated
Show resolved
Hide resolved
4a27a27 to
ac08ce6
Compare
src/libraries/System.Private.CoreLib/src/System.Private.CoreLib.Shared.projitems
Outdated
Show resolved
Hide resolved
|
I think the main remaining piece is perf testing. |
|
@MihuBot benchmark System.Collections.Concurrent |
|
@MihuBot benchmark System.Threading |
System.Collections.Concurrent.IsEmpty_String_
System.Collections.Concurrent.IsEmpty_Int32_
System.Collections.Concurrent.Count_String_
System.Collections.Concurrent.Count_Int32_
System.Collections.Concurrent.AddRemoveFromSameThreads_String_
System.Collections.Concurrent.AddRemoveFromSameThreads_Int32_
System.Collections.Concurrent.AddRemoveFromDifferentThreads_String_
System.Collections.Concurrent.AddRemoveFromDifferentThreads_Int32_
|
System.Threading.Tests.Perf_Volatile
System.Threading.Tests.Perf_Timer
System.Threading.Tests.Perf_ThreadStatic
System.Threading.Tests.Perf_ThreadPool
System.Threading.Tests.Perf_Thread
System.Threading.Tests.Perf_SpinLock
System.Threading.Tests.Perf_SemaphoreSlim
System.Threading.Tests.Perf_Monitor
System.Threading.Tests.Perf_Lock
System.Threading.Tests.Perf_Interlocked
System.Threading.Tests.Perf_EventWaitHandle
System.Threading.Tests.Perf_CancellationToken
System.Threading.Tasks.Tests.Perf_AsyncMethods
System.Threading.Tasks.ValueTaskPerfTest
System.Threading.Channels.Tests.UnboundedChannelPerfTests
System.Threading.Channels.Tests.SpscUnboundedChannelPerfTests
System.Threading.Channels.Tests.BoundedChannelPerfTests
|
|
Can we run TechEmpower too? |
|
Do you know if we have a bot to run it? Otherwise I can run crank locally to validate on Monday. |
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
|
|
||
| internal static void EnsureDetachedThreadCleanupThreadExists() | ||
| { | ||
| // We should only need to use a separate cleanup thread if we're on the finalizer thread. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we still have the deadlock problem if the user code is waiting on a finalizer thread using hand-rolled synchronization (not one of ours) and the action that it is waiting for is blocked on observing an abandoned mutex?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am wondering whether the dedicated cleanup thread is worth the trouble. I do not think we consider blocked finalizer thread to be something to be robust against in general. Blocking on a finalizer thread is a bug in the user code that can cause all sorts of problems.
Maybe we should keep it simple, wait if somebody will ever report this, and only consider fixing it then if the scenario looks plausible?
|
/benchmark plaintext,json aspnet-citrine-lin kestrel That used to work :/ |
|
/benchmark plaintext,json,fortunes aspnet-citrine-lin runtime,libs |
|
It used to work 2 weeks ago #121887 (comment) |
|
Benchmark started for plaintext, json, fortunes on aspnet-citrine-lin with runtime, libs. Logs: link |
|
An error occurred, please check the logs |
Use the shared managed wait subsystem for CoreCLR's managed code instead of the Win32 PAL
Also, remove the named mutex support from the CoreCLR PAL as well as Mutex support.
Unblocks #115685