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