Wait for the native thread to die in Thread.Join() on Windows #5037

ntherning · 2017-06-14T13:10:03Z

This is the behavior of .NET. After this patch the code on Mono for Windows will make sure the underlying native thread of a runtime created thread has died before Thread.Join() returns.

This PR should make some of the tests in WaitHandleTest less flaky on Windows.

vargaz · 2017-06-14T18:27:08Z

mono/metadata/threads.c

Doesn't mono_join_uninterrupted () already do this ?

Shouldn't this use the same mechanics as mono_threads_join_threads ?

@vargaz IIUC mono_join_uninterrupted waits for an event to be signalled in the other thread (in mono_threads_signal_thread_handle which is called by unregister_thread). When the event is signalled the native thread has not yet been fully terminated.

@kumpera I guess you mean doing something similar to https://github.com/mono/mono/blob/master/mono/metadata/threads.c#L5048? Is that entire sequence starting with MONO_ENTER_GC_SAFE required?

I mean using that very thing, but replacing pthread_join with WaitOne

luhenry · 2017-06-14T22:33:06Z

@niklas why is it flaky if we don't do that? Isn't it less flaky because some cases of races have just less chances of happening because it's a bit slower?

ntherning · 2017-06-15T06:04:59Z

@luhenry The tests in WaitHandleTest which checks for abandoned mutexes on Windows. On Windows the mutex state won't change to abandoned until the native thread has died completely. But Our Thread.Join() doesn't guarantee this so there's a slight chance that Join() returns and the mutex state is checked before the other thread is completely dead. Those tests fail every now and then on Windows as you can see in Jenkins and locally. I cannot reproduce this failure on .NET so I assume that Thread.Join() in .NET doesn't return until the native thread of the other thread is actually terminated.

ntherning · 2017-06-19T06:46:06Z

build

ntherning · 2017-06-20T07:49:46Z

This appears to build fine and tests run as expected. Any objections to merging it? @kumpera You had a comment on the implementation?

ntherning · 2017-06-27T08:51:38Z

@kumpera @luhenry Please comment if there's anything I need to change in this PR. I'll merge this later this week if I hear no objections.

kumpera · 2017-06-27T19:39:14Z

@ntherning I think we must first explore on whether extending the existing thread join code from unix to windows would not solve it.

We do it in this way to ensure proper lifetime of the underlying OS primitive and I'm not sure your approach allows for it.

ntherning · 2017-06-28T07:33:32Z

@kumpera One thing this PR addresses is the abandoned mutex issue which makes WaitHandleTest.WaitAnyWithSecondMutexAbandoned fail randomly. If we want to keep using real Windows mutexes I don't see how we can replicate the behavior of .NET without waiting for the underlying native thread to die in Thread.Join() like mono will do with this PR applied. To my knowledge there's no way to set a Windows mutex to abandoned without the owning native thread actually dying without releasing it.

The alternative to this PR would be to change Mutex on Windows to emulate mutexes using some other OS primitive and maintain the state ourselves, similarly to how it's done on unix. But that would break interoperability when managed code and native code are sharing mutexes. So not really an option.

vargaz · 2017-06-28T07:50:36Z

Wouldn't calling mono_native_thread_join () solve this ?

ntherning · 2017-06-28T08:19:51Z

mono_native_thread_join() does almost exactly what the PR does (calls WaitForSingleObject()). I can make that change.

I don't think this is what @kumpera had in mind though, but rather, if possible, align the thread joining on Windows with what we do on unix. As I tried to explain I don't think there's a way to do that while replicating what .NET does regarding mutexes.

ntherning · 2017-08-07T12:30:04Z

@kumpera I still need your comment on my previous reply.

luhenry · 2017-08-07T14:03:06Z

@ntherning if I understand correctly what @kumpera means is: please modify mono_thread_join / mono_threads_join_threads / mono_threads_add_joinable_thread to support win32, and use these functions, so we can use the same mechanism between Unix and Windows.

This is the behavior of .NET. After this patch the code on Mono for Windows will make sure the underlying native thread of a runtime created thread has died before Thread.Join() returns.

ntherning · 2017-08-23T14:36:35Z

But AFAICT ves_icall_System_Threading_Thread_Join_internal(), which this PR patches, doesn't use any of those functions you mention on any platform. This PR is about aligning the behavior of Thread.Join() on Mono on Windows with that of .NET, which will fix the problems we see in MonoTests.System.Threading.WaitHandleTest.WaitAnyWithSecondMutexAbandoned. I'm not trying to make other thread joins (internal to the runtime) behave like this on Windows. I don't think that is even desirable.

kumpera · 2017-08-23T20:34:20Z

Hi Niklas,

How about the following:

move threads.c:mono_join_uninterrupted to the w32 layer (or mono-thread depending on fit).
keep the current code as is for the unix version
On the windows version, do a WaitOne on the actual thread code.

kumpera · 2017-08-23T20:34:45Z

mono/metadata/threads.c

+		if (is_runtime_thread) {
+			// The thread was created by the runtime. Make sure the underlying
+			// native thread has terminated before we return.
+			WaitForSingleObjectEx (thread->native_handle, INFINITE, FALSE);


This is wrong, the WaitOne should respect the timeout of the icall.

vargaz · 2017-08-24T02:42:51Z

How about we call mono_native_thread_join () which should do the same ?

kumpera · 2017-08-24T20:31:02Z

@vargaz AFAICT, we can't do that cuz pthread_join would fail on detached threads.
This is one of the reasons we have this convoluted thing in place.

OTOH, we could merge this as is and queue cleanup work to follow it. In such case, we'd only need to address the join timeout issue.

vargaz · 2017-08-24T20:32:28Z

We don't detach threads anymore, i.e. don't call pthread_detach ().

kumpera · 2017-08-24T20:42:56Z

Then I guess it's about how much @ntherning wants to go down the rabbit role.

vargaz · 2017-08-29T01:38:59Z

Superseded by #5454.

dnfclas added the cla-already-signed label Jun 14, 2017

vargaz reviewed Jun 14, 2017

View reviewed changes

ntherning force-pushed the wait-for-native-thread-to-die-in-Thread-Join-on-windows branch from a100cbb to a54c7ac Compare June 16, 2017 11:36

Wait for the native thread to die in Thread.Join() on Windows

6bf491a

This is the behavior of .NET. After this patch the code on Mono for Windows will make sure the underlying native thread of a runtime created thread has died before Thread.Join() returns.

ntherning force-pushed the wait-for-native-thread-to-die-in-Thread-Join-on-windows branch from a54c7ac to 6bf491a Compare August 23, 2017 13:54

ntherning requested a review from luhenry as a code owner August 23, 2017 13:54

kumpera reviewed Aug 23, 2017

View reviewed changes

vargaz approved these changes Aug 25, 2017

View reviewed changes

ntherning mentioned this pull request Aug 28, 2017

[runtime] Wait for the thread to really exit in Thread.Join (). #5454

Merged

vargaz closed this Aug 29, 2017

Wait for the native thread to die in Thread.Join() on Windows #5037

Wait for the native thread to die in Thread.Join() on Windows #5037

Uh oh!

Conversation

ntherning commented Jun 14, 2017

Uh oh!

vargaz Jun 14, 2017

Choose a reason for hiding this comment

Uh oh!

kumpera Jun 14, 2017

Choose a reason for hiding this comment

Uh oh!

ntherning Jun 15, 2017

Choose a reason for hiding this comment

Uh oh!

kumpera Jun 27, 2017

Choose a reason for hiding this comment

Uh oh!

luhenry commented Jun 14, 2017

Uh oh!

ntherning commented Jun 15, 2017

Uh oh!

ntherning commented Jun 19, 2017

Uh oh!

ntherning commented Jun 20, 2017

Uh oh!

ntherning commented Jun 27, 2017

Uh oh!

kumpera commented Jun 27, 2017

Uh oh!

ntherning commented Jun 28, 2017

Uh oh!

vargaz commented Jun 28, 2017

Uh oh!

ntherning commented Jun 28, 2017

Uh oh!

ntherning commented Aug 7, 2017

Uh oh!

luhenry commented Aug 7, 2017

Uh oh!

ntherning commented Aug 23, 2017

Uh oh!

kumpera commented Aug 23, 2017

Uh oh!

kumpera Aug 23, 2017 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vargaz commented Aug 24, 2017

Uh oh!

kumpera commented Aug 24, 2017

Uh oh!

vargaz commented Aug 24, 2017

Uh oh!

kumpera commented Aug 24, 2017

Uh oh!

vargaz commented Aug 29, 2017

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

kumpera Aug 23, 2017 •

edited

Loading