| commit | 3b19228a668644e19944258d14124442cabf3003 | |
| author | Ryan Lucia <rylucia@microsoft.com> | |
| Tue, 14 Jan 2020 21:01:13 +0000 (14 16:01 -0500) | ||
| committer | Alexander Köplinger <alex.koeplinger@outlook.com> | |
| Tue, 14 Jan 2020 21:01:13 +0000 (14 22:01 +0100) | ||
| tree | f219fcf4163b9038d0b4c65f916fa81d4ebe5417 | treesnapshot (tar.gz zip) |
| parent | 05f2651a12ba5eae1de8b488c4026145622b265a | commitdiff |
[netcore] Implement Thread.GetCurrentProcessorId (#18450)
CoreCLR has a managed cache surrounding this, but for the moment the naive implementation will suffice. We can later move their managed cache to shared on top of this PR with minimal trouble.
We can't guarantee the id will be [0..CpuCount) for a variety of reasons, and a followup PR to the dotnet docs will clarify this. I've chosen not to intentionally add an offset, but no one should be relying on that behavior, and if someone thinks adding an offset would drive the point home the perf cost is irrelevant.
CoreCLR has a managed cache surrounding this, but for the moment the naive implementation will suffice. We can later move their managed cache to shared on top of this PR with minimal trouble.
We can't guarantee the id will be [0..CpuCount) for a variety of reasons, and a followup PR to the dotnet docs will clarify this. I've chosen not to intentionally add an offset, but no one should be relying on that behavior, and if someone thinks adding an offset would drive the point home the perf cost is irrelevant.