Skip to content
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

Add APIs for some threading metrics #28755

Closed
kouvel opened this issue Feb 21, 2019 · 11 comments
Closed

Add APIs for some threading metrics #28755

kouvel opened this issue Feb 21, 2019 · 11 comments

Comments

@kouvel
Copy link
Member

@kouvel kouvel commented Feb 21, 2019

From https://github.com/dotnet/coreclr/issues/20372

    public static class ThreadPool
    {
        public static long CompletedWorkItemCount { get; }
        public static long PendingLocalWorkItemCount { get; }
        public static long PendingGlobalWorkItemCount { get; }
        public static long PendingWorkItemCount { get; }
        public static int ThreadCount { get; }
    }

    public static class Monitor
    {
        public static long LockContentionCount { get; }
    }
  • ThreadPool.CompletedWorkItemCount
    • Gets the number of work items that have been processed so far
    • For a thread pool implementation that may have different types of work items, the count includes all types (user work items including tasks, timer callbacks, wait callbacks, and IO completions)
    • Changes over units of time would be plottable and would allow calculating throughput and average work item duration
    • There is some overhead in tracking this information, but it seems to be negligible
  • ThreadPool.PendingLocalWorkItemCount
    • Gets the number of local work items that are currently queued to be processed
    • Local work items are work items queued in some fashion that has association with a particular thread or its execution environment, and are typically processed in last-in-first-out order. They may include tasks and work items queued with QueueUserWorkItem(..., preferLocal: true).
  • ThreadPool.PendingGlobalWorkItemCount
    • Gets the number of global work items that are currently queued to be processed
    • Global work items are shared by all thread pool worker threads and are typically processed in first-in-first-out order. See PendingWorkItemCount for other relevant remarks.
  • ThreadPool.PendingWorkItemCount
    • Gets the number of work items that are currently queued to be processed
    • For a thread pool implementation that may have different types of work items, the count may not include all types. The count may only include user work items including tasks. Some implementations may also include queued timer and wait callbacks in the count. On Windows, the count is unlikely to include the number of pending IO completions, as they get posted directly to an IO completion port.
  • ThreadPool.ThreadCount
    • Gets the number of thread pool threads that currently exist
    • For a thread pool implementation that may have different types of threads, the count includes all types
  • Monitor.LockContentionCount
    • Gets the number of times there was contention upon trying to take a Monitor's lock so far
    • Changes over units of time would be plottable and would allow calculating frequency of contention

CC @noahfalk @stephentoub @sywhang @vancem

@kouvel kouvel self-assigned this Feb 21, 2019
kouvel referenced this issue in kouvel/corert Feb 21, 2019
…ixes

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on dotnet/coreclr#22754
- Fixed `Timer` implementation on Unixes. Previously there was only ever one timer request from the upper-level implementation and that is not the case anymore, so the lower-level "app domain timer" implementation needed to handle multiple timer requests.
kouvel referenced this issue in kouvel/corert Feb 21, 2019
…ixes

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on dotnet/coreclr#22754
- Fixed `Timer` implementation on Unixes. Previously there was only ever one timer request from the upper-level implementation and that is not the case anymore, so the lower-level "app domain timer" implementation needed to handle multiple timer requests.
@danmoseley
Copy link
Member

@danmoseley danmoseley commented Feb 22, 2019

Since area owner is proposing this, I guess it is ready for review.

@kouvel
Copy link
Member Author

@kouvel kouvel commented Feb 22, 2019

I think we have already discussed most of the things on the other issue, but if anyone has any suggestions on naming or behavior, please let me know.

@kouvel
Copy link
Member Author

@kouvel kouvel commented Feb 23, 2019

There is also this related request: https://github.com/dotnet/corefx/issues/34277. Perhaps we could also add properties like PendingLocalWorkItemCount and PendingGlobalWorkItemCount in addition. In CoreCLR the global one can include work items from the unmanaged side. As for "local"/"global", that distinction in naming and behavior is already there in a QueueUserWorkItem overload. The total is probably also good to have.

@kouvel
Copy link
Member Author

@kouvel kouvel commented Mar 6, 2019

Updated proposal inline to include PendingLocalWorkItemCount and PendingGlobalWorkItemCount

@kouvel
Copy link
Member Author

@kouvel kouvel commented Mar 18, 2019

@terrajobst, would it be possible to review this soon? The work to expose these is currently targeted for 3.0 and there is other 3.0 work to expose event counters that depends on this.

@ghuntley
Copy link
Member

@ghuntley ghuntley commented Mar 19, 2019

@terrajobst
Copy link
Member

@terrajobst terrajobst commented Mar 19, 2019

Video

Looks good.

The only concern is about local vs. global. Unless there is a specific scenario needing the differentiation. If there isn't we should just expose the total.

kouvel referenced this issue in dotnet/coreclr Apr 20, 2019
Implement APIs for some threading metrics (CoreCLR)

API review: https://github.com/dotnet/corefx/issues/35500
Dotnet-GitSync-Bot referenced this issue in Dotnet-GitSync-Bot/corert Apr 22, 2019
…4113)

Implement APIs for some threading metrics (CoreCLR)

API review: https://github.com/dotnet/corefx/issues/35500

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Dotnet-GitSync-Bot referenced this issue in Dotnet-GitSync-Bot/mono Apr 22, 2019
…4113)

Implement APIs for some threading metrics (CoreCLR)

API review: https://github.com/dotnet/corefx/issues/35500

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
jkotas referenced this issue in dotnet/corert Apr 22, 2019
…4113)

Implement APIs for some threading metrics (CoreCLR)

API review: https://github.com/dotnet/corefx/issues/35500

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
jkotas referenced this issue in dotnet/corert Apr 23, 2019
* Implement APIs for some threading metrics (CoreRT)

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on dotnet/coreclr#22754

* Use thread-locals for counting, use finalizer instead of runtime to detect thread exit

* Don't let the count properties throw OOM

* Remove some flushes
Dotnet-GitSync-Bot referenced this issue in Dotnet-GitSync-Bot/coreclr Apr 23, 2019
* Implement APIs for some threading metrics (CoreRT)

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on dotnet#22754

* Use thread-locals for counting, use finalizer instead of runtime to detect thread exit

* Don't let the count properties throw OOM

* Remove some flushes

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
Dotnet-GitSync-Bot referenced this issue in Dotnet-GitSync-Bot/corefx Apr 23, 2019
* Implement APIs for some threading metrics (CoreRT)

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on dotnet/coreclr#22754

* Use thread-locals for counting, use finalizer instead of runtime to detect thread exit

* Don't let the count properties throw OOM

* Remove some flushes

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
stephentoub referenced this issue in dotnet/corefx Apr 23, 2019
* Implement APIs for some threading metrics (CoreRT)

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on dotnet/coreclr#22754

* Use thread-locals for counting, use finalizer instead of runtime to detect thread exit

* Don't let the count properties throw OOM

* Remove some flushes

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
jkotas referenced this issue in dotnet/coreclr Apr 23, 2019
* Implement APIs for some threading metrics (CoreRT)

- API review: https://github.com/dotnet/corefx/issues/35500
- May depend on #22754

* Use thread-locals for counting, use finalizer instead of runtime to detect thread exit

* Don't let the count properties throw OOM

* Remove some flushes

Signed-off-by: dotnet-bot <dotnet-bot@microsoft.com>
stephentoub referenced this issue in dotnet/corefx May 9, 2019
* Expose and test APIs for some threading metrics (CoreFX)

- API review: https://github.com/dotnet/corefx/issues/35500
- Depends on dotnet/coreclr#22754, dotnet/corert#7066

* Separate and expose pending local vs global work item count

* Remove local/global variants of PendingWorkItemCount

* Remove unrelated test

* Add test for a fix to ThreadLocal.Values property throwing NullReferenceException when disposed

Fix is in dotnet/corert#7066

* Fix build

* Fix test

* Add API compat baselines for uapaot

* Fix test

* Use RemoteExecutor for MetricsTest

* Address feedback
@danmoseley
Copy link
Member

@danmoseley danmoseley commented May 28, 2019

@kouvel I guess this stays open because dotnet/corefx#37401 was only part of the work?

@kouvel
Copy link
Member Author

@kouvel kouvel commented May 28, 2019

This was only meant to be open until the APIs were exposed, closing with dotnet/corefx#37401

@kouvel kouvel closed this May 28, 2019
@danmoseley
Copy link
Member

@danmoseley danmoseley commented May 28, 2019

@kouvel I meant because you didn't expose all the above, but I guess that was intentional
dotnet/corefx@abc1e2c

@kouvel
Copy link
Member Author

@kouvel kouvel commented May 28, 2019

Oh ok, yes that was intentional. We had decided to start with not distinguishing local vs global work items, and those could be added later if needed.

@msftgits msftgits transferred this issue from dotnet/corefx Feb 1, 2020
@msftgits msftgits added this to the 3.0 milestone Feb 1, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Dec 14, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants