Thanks to visit codestin.com
Credit goes to github.com

Skip to content
This repository was archived by the owner on Nov 1, 2020. It is now read-only.

Conversation

jkoritzinsky
Copy link
Member

@dnfclas
Copy link

dnfclas commented Jul 12, 2017

@jkoritzinsky,
Thanks for having already signed the Contribution License Agreement. Your agreement was validated by .NET Foundation. We will now review your pull request.
Thanks,
.NET Foundation Pull Request Bot

@kouvel
Copy link
Contributor

kouvel commented Jul 22, 2017

It looks like I missed a bunch of commits in the issue. There are two PRs with most of the perf changes: dotnet/coreclr#9234 and dotnet/coreclr#9279. They weren't squashed before merging and I initially missed the other commits.

Considering that there are currently a significant number of differences between the CoreCLR and CoreRT implementations (with most of the fixes occurring in CoreCLR), I think it would be best to port the CoreCLR implementation of ThreadPool.cs over wholesale except for the few changes that were made specifically to CoreRT.

Probably after UWP6.0 though at this point. @sergiy-k, when would UWP6.0 split into a separate branch and master become future?

@jkoritzinsky
Copy link
Member Author

I've updated the rest of ThreadPool as well as our implementation of (LowLevel)ConcurrentQueue.

I'll mark this no merge until we know for sure that the UWP 6.0 release branch has been forked.

@sergiy-k
Copy link
Contributor

The branch has been forked. Feel free to merge once everything works correctly in your change.

@jkoritzinsky
Copy link
Member Author

@kouvel Can you take a look and make sure I didn't miss anything?

// surface to eliminate a dependency on System.Collections.Concurrent.
// Please try to keep this in sync with the public ConcurrentQueue implementation.
//
// =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep this comment for now

/// This makes a note in the state flags so that we avoid any costly synchronous operations in the finish codepath
/// such as inlined continuations
/// </summary>
/// <param name="delegateRan">Whether the delegate was executed.</param>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in this file are not necessary. Anything related to thread abort can be removed, since thread abort is not supported. They can be removed from the .NET Core side later as well.

///// The ThreadPool calls this if a ThreadAbortException is thrown while trying to execute this workitem.
///// </summary>
//void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ }
void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stuff related to thread abort can be removed

}
}
}
catch (ThreadAbortException tae)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stuff related to thread abort can be removed

Debug.Assert(setSuccessfully, "Should have been able to complete task");
}
//void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ }
void IThreadPoolWorkItem.MarkAborted(ThreadAbortException tae) { /* nop */ }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stuff related to thread abort can be removed

using System.Diagnostics;
using System.Diagnostics.Contracts;
using System.Runtime.InteropServices;
using System.Collections.Concurrent;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There are still a fair number of differences. Eventually it would be best to put most of the code in the shared folder but for now I think it would be easiest to eliminate all of the insignificant differences and only keep the differences that were intentionally made on the CoreRT side.

@jkoritzinsky jkoritzinsky changed the title Port TrySteal fix over from CoreCLR. Port Perf fixes over from CoreCLR. Aug 4, 2017
Copy link
Contributor

@kouvel kouvel left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM otherwise, thanks!

using System.Diagnostics.Contracts;
using System.Runtime.InteropServices;
using System.Collections.Concurrent;
using System.Diagnostics.CodeAnalysis;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please keep the usings sorted

private readonly Object _state;

internal _ThreadPoolWaitOrTimerCallback(WaitOrTimerCallback waitOrTimerCallback, Object state, bool flowExecutionContext)
internal _ThreadPoolWaitOrTimerCallback(WaitOrTimerCallback waitOrTimerCallback, Object state, bool compressStack)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous parameter name is better (flowExecutionContext), I believe that name was purposefully used here since compressed stack is not relevant

@jkoritzinsky jkoritzinsky merged commit 703c124 into dotnet:master Aug 8, 2017
@jkoritzinsky jkoritzinsky deleted the PortTryStealPerf branch August 8, 2017 21:28
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants