• 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

Collections and multi-threading

 
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What could be the problems if I don't use synchronized collections or new concurrent collections and write the program as follows.

 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

M Mehta wrote:What could be the problems if I don't use synchronized collections or new concurrent collections and write the program as follows.



That depends entirely on how you use this class.

What problems do you think could arise?
 
M Mehta
Ranch Hand
Posts: 92
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
What if multiple threads try to withdraw amount. Will making the two methods synchronize suffice or is it necessary to use one of synchronized version of map?
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

M Mehta wrote:Will making the two methods synchronize suffice or is it necessary to use one of synchronized version of map?



I have no idea what you're saying here. However, the general rule is that if any data can be written by one thread at the same time that it's being read or written by another thread, then all access to that data must be synchronized. If any operation needs to occur atomically, you have to synchronize around that operation.

There are higher level constructs in java.util.concurrent that can shield you from the low-level details of syncing, but they all build on the above concepts.
 
Bartender
Posts: 4179
22
IntelliJ IDE Python Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In your specific sample, you only have one piece of persistent data - the notes Map. That Map is iterated over in both the methods but doesn't appear to be modified. The problem is it is passed in from the outside, and so the Map could be modified from an external source. If that happens this class would be unsafe, and there is very little you could do to protect yourself from it.

You should make a local, read-only copy of the notes Map in the constructor. If you do that then the class should be thread safe without any further synchronization needs.
 
Jeff Verdegan
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Steve Luke wrote:In your specific sample, you only have one piece of persistent data - the notes Map. That Map is iterated over in both the methods but doesn't appear to be modified. The problem is it is passed in from the outside, and so the Map could be modified from an external source. If that happens this class would be unsafe, and there is very little you could do to protect yourself from it.

You should make a local, read-only copy of the notes Map in the constructor. If you do that then the class should be thread safe without any further synchronization needs.



It seems odd that the Map member variable is never modified. We have an instance of an ATM, but calling withdraw() doesn't alter the state of that ATM? There's a bit of design smell there.

@OP: Maybe you have a good reason for doing that, or maybe you're just not showing us the entire class. As the code stands, Steve is correct--since you don't modify the map, as long as you make a copy at construction time, you're safe. However, if there's any way that Map can get modified then you need synchronization. And note that while you're copying the Map for constructing an ATM, if anything else can modify that original Map, then you need synchronization.

Finally, I'll just point out that the "M" in "ATM" stands for "Machine," so your class name has some redundancy.

("Enter your PIN number into the ATM machine" --> "Enter your Personal Identification Number number into the Automatic Teller Machine machine.")
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic