Disable parallelism in PerfCounter tests

[danmoseley]

Fixes #25400 (?)

There is at least some attempt at thread safety in the performance counters API but it seems quite that the data structures are not fully protected against eg modifying categories while concurrently enumerating them or reading counters. For example, _customCategoryTable, a HashTable, is modified here without protection against concurrent write at this same location (or in other places).

It is also possible that the results of multiple registry reads (eg for categories, instances, and data) are becoming mutually inconsistent because of intervening concurrent modifications to categories, etc.

Rather than attempt to analyze the possibilities (which we might not want to attempt to "fix" anyway) let's try running the tests serially.

[stephentoub]

For example, _customCategoryTable, a HashTable, is modified here without protection against concurrent write at this same location (or in other places).

Is there an issue open for that? You're right about this being busted, and the data structure could easily end up getting corrupted.

Rather than attempt to analyze the possibilities (which we might not want to attempt to "fix" anyway) let's try running the tests serially.

Assuming the issue is the lack of thread-safety in the implementation, running the tests serially is a reasonable short-term workaround, but the real fix is obviously to fix the implementation. It's also possible there are conflicts between tests, where multiple tests running in parallel are making modifications and the tests themselves aren't robust against that; for such situations, making the tests run serially might be the right answer, or else rewriting the tests to be reliable in such an environment.

[danmoseley]

@stephentoub I can open an issue, but do we expect this code to be thread safe? The docs have the usual boilerplate Any instance members are not guaranteed to be thread safe. although there are also allusions to some internal locks being taken. The locks are evidence that some attempt was made to be safe, but we probably don't want to invest in making it waterproof unless we have documented that it is.

[danmoseley]

The EventLog test flakiness may possibly need a similar "remedy"

[danmoseley]

where multiple tests running in parallel are making modifications and the tests themselves aren't robust against that

This is very possible, but @adiaaida tried to avoid this, eg., by having each test use a category with its own name in it, etc..

[stephentoub]

but do we expect this code to be thread safe?

@danmosemsft, aren't these PerformanceCounterLib instances stored in a static table and published for multiple threads to all work with? At that point instance state on PerformanceCounterLib isn't really instance state, it's shared state.

[danmoseley]

Yes, the PerformanceCounterLib you get is the only one in your process for that target machine/LCID. OK, I'll open a bug.