loom-dev Digest, Vol 28, Issue 3

[Ron Pressler]

Both “carrier locals” and “processor locals” can only make the same guarantees, which are
very weak, as descheduling (either by the kernel or the virtual thread scheduler) can happen
at pretty much any point. If we add processor locals, the API is very similar to that of a CAS,
and the only difference is that, on Linux, it can be faster than an actual CAS.

For striping, it’s best to just use j.u.c.LongAdder/Accumulator which should work well with 
virtual threads (if it doesn’t yet, it will), as would TLRandom. For hand-rolled striping, the 
best you can expect is a faster CAS, i.e. not something that everyone should use.

Even if there was a general way to make it easier, letting things that are “not thread-safe and 
expensive to create” freely leak between threads is not something I’m crazy about. I think that
with or without Loom it’s best to either make those things thread-safe or cheap to create.

- Ron


On 3 April 2020 at 16:14:28, Douglas Surber (douglas.surber at oracle.com) wrote:

I agree with Kasper. All my uses of thread local are to avoid contention and all would be addressed by a processor local with the very important caveat that the points where the processor can change are well defined and easily recognized. In practice I have a feeling that would not be practical. Stepping away from implementation, what I need is something like this:  

public final class LocalResource<T> {  
private final Supplier<T> creator;  
public LocalResource(Supplier<T> c) {  
creator = c;  
}  
private T get() { ... }  
private void release(T resource) { ... }  
public <V> V do(Function<T, V> f) {  
T t = this.get();  
try {  
return f.apply(t); // capturing t in f is an error  
}  
finally {  
this.release(t);  
}  
}  
}  

An instance of LocalResource creates and retains the minimum number of instances of T necessary to satisfy all calls to do without any contention. Assume T is not thread safe and expensive to create. A LocalResource is used like this:  

Bar b = new Bar();  
Foo f = resource.do( t -> t.foo(b) );  

Presently we use ThreadLocal for this purpose, but ThreadLocal implies an implementation. ProcessorLocal would also imply an implementation. I don't care how it's implemented. What I want is something that allocates a minimum number of instances of T, on the order of the number of cores, and has zero contention, ever, and is fast. If Loom provides something like LocalResource I think many of the demands on ThreadLocal are relaxed giving more freedom to specify how it works with virtual threads.  

Douglas  


> On Apr 3, 2020, at 1:57 AM, loom-dev-request at openjdk.java.net wrote:  
>  
> Date: Fri, 3 Apr 2020 08:35:03 +0100  
> From: Kasper Nielsen <kasperni at gmail.com <mailto:kasperni at gmail.com>>  
> To: Thomas May <tmay at clearwateranalytics.com <mailto:tmay at clearwateranalytics.com>>,  
> dmitry.zaslavsky at gmail.com <mailto:dmitry.zaslavsky at gmail.com>  
> Cc: "loom-dev at openjdk.java.net <mailto:loom-dev at openjdk.java.net>" <loom-dev at openjdk.java.net <mailto:loom-dev at openjdk.java.net>>  
> Subject: Re: carrier local  
> Message-ID:  
> <CAPs6152sBjL4u8dXskvhpR5v4cXKNoBzeN2tdKdf0xnOqUY1Mg at mail.gmail.com <mailto:CAPs6152sBjL4u8dXskvhpR5v4cXKNoBzeN2tdKdf0xnOqUY1Mg at mail.gmail.com>>  
> Content-Type: text/plain; charset="UTF-8"  
>  
> On Thu, 2 Apr 2020 at 21:07, Thomas May <tmay at clearwateranalytics.com <mailto: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 <https://cr.openjdk.java.net/~rpressler/loom/Loom-Proposal.html>  
> [2] https://bugs.openjdk.java.net/browse/JDK-7065539 <https://bugs.openjdk.java.net/browse/JDK-7065539>  
>