• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

hashmap of locked records and static

 
Ranch Hand
Posts: 32
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

I use a hashmap to keep track of the recordslocked
My data class is NOT static but my hashmap IS static.
I synchronized on this hashmap before adding or removing a record in the map.
So I don't need to use a thread safe hash map or vector if I use a static data and static hashmap?
Can somebody confirm that I am right on this?
Thank you very much
- Lydie
 
author and jackaroo
Posts: 12200
280
Mac IntelliJ IDE Firefox Browser Oracle C++ Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Lydie,

Even with a static collection, you still have the potential for two threads to access the collection simultaneously. So you still need thread-safe access.

A good start to this is synchronizing any access to the collection that modifies the collection (which you do). However this does not go far enough - there is still the potential that one thread could try and retrieve data from the collection while another thread is modifying it. If the modification changes the size of the underlying data structure (currently an array) then the thread doing the retrieval could get a NullPointerException or retrieve no data, or retrieve the wrong data, or retrieve the correct data - there is no way of telling what might occur.

So to guard against this you will need to sychronize all access to the collection. You could do this manually (since you already synchronize modification of the collection you only need to synchronize read access to the collection), or you could make the entire collection thread safe (take a look at the synchronizedMap method of java.util.Collections (or any of the other synchronized collections available through the Collections class).

This is one area that there is no "one right way" to handle thread safe access. If your collection access routines are already in sychronized blocks that ensure thread-safe access then you don't need a synchronized collection. But if your collection access is not within a synchronize block then a synchronized collection may save you the effort of synchronizing the access yourself (and keep your code simpler / more readable).

I recommend staying clear of Hashtable and/or Vector though - although they are internally synchronized, it is rarely clear in their usage whether the coder deliberately chose them for that reason, or whether the coder was unaware of other collection classes (or, in real work, whether their use is part of legacy code). In any case a person looking at your code may not realize that you are reliant on the thread-safe behaviour of Hastable or Vector and change it - with disasterous results. Make it explicitly clear by using Collections.synchronizedXxxx or (if you don't need synchronized collections) by using a plain Collection.

Regards, Andrew
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic