aspose file tools*
The moose likes Java in General and the fly likes Collections and multi-threading Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Collections and multi-threading" Watch "Collections and multi-threading" New topic
Author

Collections and multi-threading

M Mehta
Ranch Hand

Joined: Aug 03, 2006
Posts: 92
What could be the problems if I don't use synchronized collections or new concurrent collections and write the program as follows.

Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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

Joined: Aug 03, 2006
Posts: 92
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

Joined: Jan 03, 2004
Posts: 6109
    
    6

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.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

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.


Steve
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

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.
 
subject: Collections and multi-threading