[Bug classpath/22680] ThreadLocal and InheritableThreadLocal need to synchronize access to the map

[gcc-bugzilla at gcc dot gnu dot org]

Inside Threadlocal and InheritableThreadLocal are comments like:

// Note that we don't have to synchronize, as only this 
//thread will ever modify the returned value.

While it is true that only one thread will ever deal with the return value from
the map, the map itself is written and read concurrently by multiple threads.
Hence access to the map *must* be synchronized.

Note that there is a much better way to implement thread locals that avoids the
need for any synchronization. Unfortunately I can't say anymore as the
technique is used by the JDK. Think carefully about what it means to be
thread-local. You might also want to checkout how other systems implement
thread-local storage.


------- Comment #1 from from-classpath at savannah dot gnu dot org  2003-07-11 
17:51 -------
At my company we have an ExecutionContext which holds data for executions,
which can be a transaction or a thread in the case of not having a transaction.
 In out case we store a map in the ExecutionContext object.  Since our code
guarantees that only one thread can be associated with the context at a time,
we do not need to synchronize on the map in the.  You should put the map for
this ThreadLocal object in the Thread object, because only that thread can be
associated with the thread.


------- Comment #2 from from-classpath at savannah dot gnu dot org  2003-08-09 
18:46 -------
Thanks for catching this. I wrapped both threadMap and valueMap inside a
Collections.synchronizedMap().

InheritableThreadLocal was designed to impact java.lang.Thread as less as
possible since all VMs have this class as a private implementation. Now that
Jeroen is going to split Thread into a VMThread and a Thread we can look again
at optimizations of InheritableThreadLocal that do impact the fields/methods of
Thread.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22680