• Port ofStop counting work items from ThreadPoolTypedWorkItemQueue for ThreadPool.CompletedWorkItemCount #106854 andMake counting of IO completion work items more precise on Windows #112793 to 9.0
• Follow-up toStop counting work items from ThreadPoolTypedWorkItemQueue for ThreadPool.CompletedWorkItemCount #106854. Issue:ThreadPool.CompletedWorkItemCount double counting IO completion work items #104284.
• Before the change, the modified test case often yields 5 or 6 completed work items, due to queue-processing work items that happen to not process any user work items. After the change, it always yields 4.
• Looks like it doesn't hurt to have more-precise counting, and there was a request to backport a fix to .NET 8, where it's more necessary to fix the issue

Customer Impact

While upgrading a service from .NET 6 to 8, a 1p customer noticed that on Windows, the "Thread Pool Completed Work Item Count" counter values roughly doubled for the service. This is due to .NET 8 also counting queue-processing work items that were introduced in .NET 7. So, for each IO completion callback run to completion, the completed work item count may change by 1-3 or more depending on the situation. Especially in services that take small amounts of periodic traffic, the completed work item count can appear to double or triple per IO completion callback run to completion. The metric is monitored closely by the customer to monitor service health, and they would like to be able to use a more representative count that reflects actual user work items that are completed, for that purpose.

Regression?

Yes, in .NET 7 on Windows

Testing

Validated in a small test case that for IO completion handling, the count reflects the actual number of IO completion callbacks run to completion.

Risk

Low, the count after the change is similar to what it used to be in .NET 6