6/13/13

A couple of threaded questions (Threads forum at JavaRanch)

Big Moose Saloon

A friendly place for programming greenhorns!
Search

Java FAQ

Recent Topics

Register / Login

A special promo: Enter your blog post or vote on a blogger to be featured in an upcoming Journal

JavaRanch Java Forums Java Threads and Synchronization

Author

A couple of threaded questions

posted 11/1/2003 9:46 PM

Tom Diamond Ranch Hand Joined: May 10, 2001 Posts: 98

Hello, Here is my problem: I have a Hashtable field which is accessed by multiple threads. Hashtable is synchronized according to the API. This means that I can access it as is without worrying about synchronization? Does it make any difference if the field is static or not? If not static should getters and setters be synchronized or not? Tnx in advance, Tom.

Liu Fei Greenhorn Joined: Oct 31, 2003 Posts: 2

posted 11/2/2003 12:14 AM

hi~ I write down my understanding about the problem. May not be correct. 1. Yes. Hashtable can be accessed without worrying about synchronization. 2. There is a lock for a class, when static field or method need be synchronized. Class lock is different from object lock. For example, class AB has two instances a and b, a synchronized method instanceMethod(), and a static synchronized method classMethod(). When instance 'a' enters the instanceMethod(), 'b' can also enter the method even if they are in two threads. But if two threads access classMethod(), they
1/4

www.coderanch.com/t/232359/threads/java/couple-threaded-questions

6/13/13

A couple of threaded questions (Threads forum at JavaRanch)

will be synchronized. 3. Yes. Since the class is under multi-thread, in general, getters and setters should be synchronized.

Originally posted by Tom Diamond: Hello, Here is my problem: I have a Hashtable field which is accessed by multiple threads. Hashtable is synchronized according to the API. This means that I can access it as is without worrying about synchronization? Does it make any difference if the field is static or not? If not static should getters and setters be synchronized or not? Tnx in advance, Tom.

Jim Yingst Wanderer Sheriff Joined: Jan 30, 2000 Posts: 18670

posted 11/2/2003 3:23 AM

I have a Hashtable field which is accessed by multiple threads. Hashtable is synchronized according to the API. This means that I can access it as is without worrying about synchronization? Sometimes - it depends what you're trying to do. One of the worst things about Hashtable and Vector is that people think anything they do with them is going to be thread-safe. That's not always the case. Individual methods of the class(es) are thread-safe, but often you need synchronization at a higher level. E.g. in something like this:
view plain c opy to c lipboard print ?

N ote: T ext c ontent in the c ode bloc ks is automatic ally word- wrapped

0 1 . 0 2 . 0 3 . 0 4 . 0 5 . 0 6 . 0 7 . 0 8 .

v o i dg e t F o o F o r ( O b j e c tk e y ){ F o of o o=( F o o )h t . g e t ( k e y ) ; i f( f o o= =n u l l ){ f o o=n e wF o o ( k e y ) ; h t . p u t ( k e y ,f o o ) ; } r e t u r nf o o ; }

Here the individual get() and put() calls are synchonized. But if more than one thread can call getFooFor(), then there may still be problems. Consider: Thread A does get("myfoo"), which is null. Thread B does get("myfoo"), which is null. Thread A creates a new Foo, puts it in the Hashtable, and returns the new Foo. Thread B creates a new Foo, puts it in the Hashtable (replacing the one A created), and returns the new Foo. So now B's new Foo() has replaced the one A created - but A is still using the first one. Is this OK? Well it depends - the Foo class may have been written with the assumption that there would be only one Foo for a given key, and now
www.coderanch.com/t/232359/threads/java/couple-threaded-questions 2/4

6/13/13

A couple of threaded questions (Threads forum at JavaRanch)

there are two. Perhaps each Foo will try to open a log file titled myfoo.txt, and the second Foo will fail because there's a FileWriter in the first Foo which is holding a lock on the newly created file. If something like that is going on, then the getFooFor() method really needs to prevent accidentally creating two Foos for the same key. And to do that, the method needs to be synchronized so that Thread B won't be able to do a get() until after Thread A has done its put(). This may seem a contrived example, but it's not too unusual to find processing done on a Hashtable which requires that other threads not interfere in between two separate Hashtable method calls. For this reason, it's dangerous to think of Hashtable as automatically thread-safe. You need to consider just what level of synchronization is really necessary for whatever problem you're trying to solve. Does it make any difference if the field is static or not? If not static should getters and setters be synchronized or not? First: Getters and setters? You mean like these? public Hashtable getHashtable() public void setHashtable(Hashtable ht) If the Hashtable reference itself is being changed (by set) rather than merely changing data inside the Hashtable, then the fact that Hashtable is "synchonized" is completely irrelevant. Here you're not using methods inside the Hashtable class, which would be synchronized, youre using methods outside the class, which aren't. So the decision as to whether or not you need to synchronize has nothing to do with the Hashtable class. So what does it depend on? The important question is, is the data mutable, and can more than one thread access that data? If we're talking about a mutable instance field, then the question is - can more than one thread access a single instance of your class? If so, then you need to synchronize. If the field is static, then the question is broader - can more than one thred access your class at all? Again, if the answer is yes, you must synchronize - on the class. Meaning use a static synchronized method rather than an instance method. So the answer depends in part on whether a field is static, but you also need to consider whether multiple threads have access or not. Many, many things in Java are not synchronized, and it's OK as long as you don't hand those things off to more than one thread. So thread safety generally certers around understanding what your threads might be doing, and what variables they have access to. And limiting access wherever possible so that you have fewer thening to worry about. Note - when I say "you must synchronize" - well, there are cases where you can get away with not synchonizing, e.g. in some cases you can use volatile instead, or you can decide that it's OK if sometimes you read invalid data, in order to increase performance. However you really shouldn't do this sort of thing unless you have a good understanding of how everyting works, and what the risks are. If you are at all uncertain about whether or not you should be synchronizing, chances are, you need to synchronize on something.

"I'm not back." - Bill Harding, Twister

I agree. Here's the link: http://aspose.com/file-tools

www.coderanch.com/t/232359/threads/java/couple-threaded-questions

3/4

6/13/13

A couple of threaded questions (Threads forum at JavaRanch)

subject: A couple of threaded questions

Similar Threads Please explain HashMap? Remove a subset of objects at once manning's question about thread safe Hashtable vs HashMap Hashtable vs. HashMap
All times above are in your local time zone & format.T he current ranch time (not your local time) is Jun 12, 2013 21:29:51 .

Contact Us | Powered by JForum |

C opyright 1998-2013 Paul W he aton

www.coderanch.com/t/232359/threads/java/couple-threaded-questions

4/4