This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Yes, you want Thread-2 to be aware that Thread-1 is busy with the key-1
object (by locking the Class object in this case), so that Thread-2 waits for
things to settle down before it is allowed to read key-1.
Why not use ConcurrentHashMap its very efficient at sorting out the minimum amount of over head ? Any time it can get away without locking it will and be more efficient than just synchronizing your hash map.
If you want to do it the hard and inefficient/slow way your almost certainly going to need the readLock for visibility if nothing else. As to what your actually updating, whatever it is needs happens before ordering usually thought of as a read memory barrier regardless of the actual locking i.e. you need a write barrier after the update and a read before the read (ok strictly you need happens before ordering as you can have that without a memory barrier literally) ... if all this is confusing I refer you to my first simple suggestion just use ConcurrentHashMap .
"Eagles may soar but weasels don't get sucked into jet engines" SCJP 1.6, SCWCD 1.4, SCJD 1.5,SCBCD 5
Joined: Jan 09, 2008
Yes Chris, I do find your explanation a bit confusing.
Can you elaborate (and/or) simplify a bit. Thanks.
The really simple answer to the question was use ConcurrentHashMap, the second best answer was just leave that readLock there (I haven't seen the code obviously so I'm guessing at what it looks like)
Assuming we're going to ignore the simple solution ..
Which bit ;-) . Could you elaborate on which bit you find confusing
the benefits of ConcurrentHashMap vs synchronized map
happens before ordering
memory barriers / fences
Java Memory Model
ConcurrentHashMap is well written up in blogs and books , it can (does its best to) allow concurrent writes and reads and assures correct publication of the data it references. I can recommend some if it helps. Also we never mentioned this but was read / write locks a good performance choice at all according to the books on my desk the answer is not always ;-)
As regards the rest , its difficult to know you level are you an expert or a novice (I suspect both read these forums) ;-) I usually start with do you understand what the volatile keyword does in the new Java Memory model (I'm not recommending volatile use its just a good level indicator) . I guess I assumed mini wasn't an expert so a simple solution was best.
Essentially if one thread writes and another reads the same memory you MUST establish establish "happens before ordering "or you run the risk your reading thread will miss your writes (they never happen in the second threads view of the world an effect like same variable two different values) possibly indefinitely ... your write and read locks are handling this for you but if you remove one of them it all gets very complicated (this is a separate issue to the actual locking) . The simplified and strictly incorrect explanation is that the without the readLock you have no guarantee that the second thread ever sees the results of the first threads writes (or you need to add something else to achieve the guarantee).
At its simplest if a class contains say a boolean with a getter and setter and one thread reads and one writes if you synchronize the set you should synchronize the get.
Joined: Jan 09, 2008
Chris: I am a relative newbee and currently working on my Java developer certification.
It seems that the original question is about proper use of the key word 'synchronized' for
a HashMap but your answer doesn't explore this. A discussion about "happens before"
skips over this simple solution provided by the language. Do you not like this tool?
The original question which is a good one and is a very common gotcha is why do I need a ReadLock and the answer is just complicated, the best thing is to just obey the simple rule and not ask ;-0 but as the question was asked directly I gave an answer. The thread was then diverted ..
I like synchronized its a wonderful keyword I use it a lot but note read and write locks were added to allow improvements to Java so to dismiss them out of hand is a mistake and they can if used correctly deliver better performance i.e. his solution could beat the synchronized one (notice I'm careful with my could)
I actually used synchronization a lot on my SCJD and did very, very nicely ;-) but most people and books will use Read and Write locks on the developer certification and I went into the essay questions fully armed with what their advantages are and how and when they affect performance e.g. % reads vs % writes etc etc . If your going to do the developer certification I would suggest a full understanding of their potential advantages should be a goal.
The thread was then diverted to what is a simpler solution and it was suggested we might use ...
I'm suggesting a simpler and quicker solution is to use ConcurrentHashMap surely its simpler to just new one than new a map and then add a synchronized wrapper. I see as the better simpler solution.
Joined: Jan 09, 2008
Chris: Are you referring to the java.util.concurrent package?
Are there other packages that also apply here?