Re: Do I need to sync Get methods that return thread-safe collections
Lew wrote:
Royan wrote:
I'm trying to find potential pitfall in unsynchronized methods that
return thread-safe collections. Assume i'm [sic] designing a thread-safe
class.
Read the articles on concurrency by Brian Goetz in IBM DeveloperWorks,
and his book /Java Concurrency in Practice/.
This is the best advice. Thread safety is complicated enough that a
couple of quick posts on Usenet won't explain everything. You need
something more thorough to give you the full picture. Java Concurrency
in Practice will give an excellent understand of many thread safety and
concurrency issue.
Case in point:
>> public class ThreadSafe {
>>
>> private Vector<String> vector;
>> /** But is OK to have such method? */
>> public Vector<String> getVector() {
>> return vector;
>> }
>> }
Nope, not ok. You created an object on one thread (not shown) and then
tried to fetch it on another. Guaranteed problems. Example:
Let's say ThreadSafe has a constructor which Thread A calls:
public ThreadSafe() {
vector = new Vector<String>();
}
Now Thread B calls getVector. Oops!! It may not even see the value of
the reference (field "vector" might be null still) or thread B might see
the Vector in a partially constructed state (there's still bits of it in
Thread A's cache which haven't been written out yet). Either way, big
trouble.
>> public class ThreadSafe {
>>
private volatile Vector<String> vector;
>> /** But is OK to have such method? */
>> public Vector<String> getVector() {
>> return vector;
>> }
>> }
Now you're safe. Making getVector() "synchronized" would do the same
thing. (The JVM knows to flush objects around the synchronized "memory
barrier.") See Java Concurrency in Practice for more....