This week's giveaway is in the EJB and other Java EE Technologies forum.
We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line!
See this thread for details.
The moose likes Threads and Synchronization and the fly likes external synchronization on a hash map Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "external synchronization on a hash map" Watch "external synchronization on a hash map" New topic
Author

external synchronization on a hash map

David Duran
Ranch Hand

Joined: Feb 11, 2002
Posts: 122
It's been awhile since I've done this so I just want to make sure I'm doing this right.
I have a global static HashMap that I do puts and gets to (no removes).
I declare them like this:
public static Map myMap = new HashMap();
public static Map myMap_sync = Collections.synchronizedMap(myMap);// for adding later
When I want to get something out I simply use the unsync'd map:
Object val = (Object)myMap.get(key);
When I want to add something I use the sync'd map and synchronize externally on it:
synchronized(myMap_sync)
{ myMap_sync.put(key, value); }
I declare the sync'd map in the beginning rather than everytime I do a put because I do lots of puts. Does this look right? Thanks
[ August 01, 2002: Message edited by: David Duran ]
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Looks unsafe to me. You're allowing gets and puts to occur at the same time. That might work OK for a primitive variable declared as volatile (if it's not long or double), but a HashMap is a more complex object - I'm pretty sure there are a number of different lookups occuring during this process which might contain garbage data if not synchronized. You really need to synchronize the gets as well as the puts. Just ditch the myMap reference entirely - use only the myMap_sync. Then no further synchronization will be necessary unless you iterate (see synchronizedMap() specs). Your current synchronized blocks for the puts are redundant, since the synchronizedMap() view already does this for you.
Note that you could also use a Hashtable instead, which is already synchronized and might be a little faster. But my feeling is that any performance gain here is small at best, and the collection framework API's are much cleaner than Vector/Enumeration/Hashtable, so just forget about the old classes. They just create extra questions for some programmers, not worth the distraction.
[ August 01, 2002: Message edited by: Jim Yingst ]

"I'm not back." - Bill Harding, Twister
David Duran
Ranch Hand

Joined: Feb 11, 2002
Posts: 122
Just ditch the myMap reference entirely - use only the myMap_sync

So myMap_sync basically is the same as a HashTable (aside syntax differences in the API)- it's methods are synchronized. Is that a correct assumption?
Synchronization is something that flies over my head.
Jim Yingst
Wanderer
Sheriff

Joined: Jan 30, 2000
Posts: 18671
Yes, pretty much. One other difference is that you can put a null key &/or null values into a HashMap but not a Hashtable (not that this matters for you here though).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: external synchronization on a hash map
 
Similar Threads
Can we Serialize a HashMap object in a Thread
How to solve the Reader and Writer problem using wait() and notify()?
Hashtable question!
Hashmap and Generics
Create Immutable HashMap