Given that a ThreadLocal variable holds different values for different threads, is it possible to access the value of one ThreadLocal variable from another thread?
I.e. in the example code below, is it possible in t1 to read the value of TLocWrapper.tlint from t2?
public class Example
{
public static void main (String[] args)
{
Tex t1 = new Tex("t1"), t2 = new Tex("t2");
new Thread(t1).start();
try
{
Thread.sleep(100);
}
catch (InterruptedException e)
{}
new Thread(t2).start();
try
{
Thread.sleep(1000);
}
catch (InterruptedException e)
{}
t1.kill = true;
t2.kill = true;
}
private static class Tex implements Runnable
{
final String name;
Tex (String name)
{
this.name = name;
}
public boolean kill = false;
public void run ()
{
TLocWrapper.get().tlint.set(System.currentTimeMillis());
while (!kill)
{
// read value of tlint from TLocWrapper
System.out.println(name + ": " + TLocWrapper.get().tlint.get());
}
}
}
}
class TLocWrapper
{
public ThreadLocal<Long> tlint = new ThreadLocal<Long>();
static final TLocWrapper self = new TLocWrapper();
static TLocWrapper get ()
{
return self;
}
private TLocWrapper () {}
}
As Peter says, this isn’t possible. If you want this sort of functionality, then conceptually what you really want is just a standard
Map<Thread, Long>– where most operations will be done with a key ofThread.currentThread(), but you can pass in other threads if you wish.However, this likely isn’t a great idea. For one, holding a reference to moribund threads is going to mess up GC, so you’d have to go through the extra hoop of making the key type
WeakReference<Thread>instead. And I’m not convinced that aThreadis a great Map key anyway.So once you go beyond the convenience of the baked-in
ThreadLocal, perhaps it’s worth questioning whether using aThreadobject as the key is the best option? It might be better to give each threads unique IDs (Strings or ints, if they don’t already have natural keys that make more sense), and simply use these to key the map off. I realise your example is contrived, but you could do the same thing with aMap<String, Long>and using keys of"t1"and"t2".It would also arguably be clearer since a
Maprepresents how you’re actually using the data structure; ThreadLocals are more like scalar variables with a bit of access-control magic than a collection, so even if it were possible to use them as you want it would likely be more confusing for other people looking at your code.