carrier local

[Dmitry Zaslavsky]

The problem with with processor locals in user mode (drivers sometime can control this) is that thread can be preempted at any time.
So for example you can’t do this
MyStats(CurrentCode).calls ++;

If you want this to be reliable.
You would have to do it atomically.
It’s an improvement of course over using Atomics on the same int for example.
It’s likely to be an order of magnitude faster, but still needs to be atomic and still slower.

API in C++ world existing for a long time, and get significantly less usage.
People do use the incorrectly once in a while and you can search for those bugs.
 


> On Apr 3, 2020, at 3:35 AM, Kasper Nielsen <kasperni at gmail.com> wrote:
> 
> On Thu, 2 Apr 2020 at 21:07, Thomas May <tmay at clearwateranalytics.com> wrote:
>> 
>> LongAdder would be a good example where you'd want carrier local storage rather than thread local.  Having it ThreadLocal would allocate more memory than necessary.
> 
> I think you would be better off with processor local state in most
> cases where you
> are trying to avoid contention as mentioned in the Loom proposal [1]
> and this RFE [2].
> 
> /Kasper
> 
> [1] https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html
> [2] https://bugs.openjdk.java.net/browse/JDK-7065539