[bug #3229] ThreadLocal and InheritableThreadLocal need to synchronize access to the map

[nobody]

=================== BUG #3229: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3229&group_id=85

Changes by: Mark Wielaard <address@hidden>
Date: Sat 08/09/03 at 20:46 (Europe/Amsterdam)

            What     | Removed                   | Added
---------------------------------------------------------------------------
          Resolution | None                      | Fixed
              Status | Open                      | Closed


------------------ Additional Follow-up Comments ----------------------------
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.



=================== BUG #3229: FULL BUG SNAPSHOT ===================


Submitted by: davidholmes             Project: classpath                    
Submitted on: Wed 04/16/03 at 08:48
Severity:  5 - Major                  Resolution:  Fixed                    
Assigned to:  None                    Status:  Closed                       
Platform Version:  None               

Summary:  ThreadLocal and InheritableThreadLocal need to synchronize access to 
the map

Original Submission:  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.

Follow-up Comments
*******************

-------------------------------------------------------
Date: Sat 08/09/03 at 20:46         By: mark
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.

-------------------------------------------------------
Date: Fri 07/11/03 at 19:51         By: None
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.


CC list is empty


No files currently attached


For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=3229&group_id=85

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/