-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
[mono] More Threading changes #49637
Conversation
src/mono/System.Private.CoreLib/src/System/Threading/Thread.Mono.Unix.cs
Outdated
Show resolved
Hide resolved
The 'Libraries Test Run release mono Linux x64 Debug' lane failure looks relevant. |
@CoffeeFlux any update here? |
@marek-safar I held off on this until after P3 and am out today and tomorrow, but I'll push my changes this Thursday. |
1f0a6a0
to
084063c
Compare
I validated that the current strategy for mutex abandonment is indeed broken, and will add a test and a fix to this before taking it out of draft. Sample program that will succeed on CoreCLR but fail with our current approach: using System;
using System.Threading;
public class Example
{
private static Mutex _orphan = new Mutex();
[MTAThread]
public static void Main()
{
Thread t = new Thread(new ThreadStart(AbandonMutex));
t.Start();
t.Join();
// Wait on the abandoned mutexes. The WaitOne returns
// immediately, because its wait condition is satisfied by
// the abandoned mutex, but on return it throws
// AbandonedMutexException.
try
{
_orphan.WaitOne();
Console.WriteLine("WaitOne succeeded.");
}
catch(AbandonedMutexException ex)
{
Console.WriteLine("Exception on return from WaitOne." +
"\r\n\tMessage: {0}", ex.Message);
}
finally
{
// Whether or not the exception was thrown, the current
// thread owns the mutex, and must release it.
//
_orphan.ReleaseMutex();
}
}
[MTAThread]
public static void AbandonMutex()
{
_orphan.WaitOne();
// Abandon the mutex by exiting without releasing it.
Console.WriteLine("Thread exits without releasing the mutexes.");
}
} |
src/libraries/System.Private.CoreLib/src/System/Threading/Thread.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/System/Threading/Thread.Mono.cs
Outdated
Show resolved
Hide resolved
Yes, that would be nice. Look for |
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.
the coop attach detach functions have non-obvious callers that depend on the return type that need to be adjusted.
I think we should be good on the Mono side other than fixing abandoning and adding an associated test. There is additional cleanup potential with #50656, but that is outside the scope of this PR. |
src/libraries/System.Private.CoreLib/src/System/Threading/WaitSubsystem.Unix.cs
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml
Outdated
Show resolved
Hide resolved
src/mono/System.Private.CoreLib/src/ILLink/ILLink.Descriptors.xml
Outdated
Show resolved
Hide resolved
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.
LGTM. Thanks for cleaning this up.
I'd avoid calling into managed while holding a lock. (I'm not sure that anything would necessarily go wrong, but it seems like it wouldn't be difficult to call outside the lock.)
Abandoning in managed seems to work fine
4f7f7fa
to
05f3665
Compare
The remaining lanes look mostly CoreCLR-related, and the Windows ones seem stalled for infra-related reasons. Everything passed pre-rebase, so merging. |
Contains: general cleanup, domain removal, and moving to sleeping from managed
We can probably also switch to setting the priority in managed, but I'll do that separately.
I have not tested this on Windows, but I assume it will work fine.
@jkotas is there argument validation for Sleep on the native side in CoreCLR I should remove now that it's happening in managed? Or would you prefer that change be Mono-only?