Thread safe classes

[palla sridhar]

Hi! I'm new to this forum and got a few doubts about Threads..
1. First let me confirm whether i'm right about this. Thread-safe classes have all their methods synchronized. Right or Wrong?
2.If i'm right,as per my knowledge these synchronized methods still need to be called from a synchronized blocks!! Then what is the use of these thread-safe class methods being synchronized, if they're still called as of a normal methods ??
3. Can anybody explain, what is the advantage of thread-safe synchronized methods and normal methods??

Thanks in advance.

[Edward Harned]

1. No
2. No
and now the big number 3. Read this: Tutorial

[Jim Yingst]

Expanding on Edward's answers:

1. Making all methods synchronized is a common strategy for making thread-safe classes, but (a) making all methods synchronized does not necessarily guarantee thread safety, and (b) it's also possible to make thread-safe classes that do not use synchronization at all, and instead use other techniques (such as the classes in java.util.concurrent).

2. Sometimes, in poorly-designed not-really-thread-safe classes like java.util.Vector and its evil twin Collections.synchronizedlist(), you may need additional synchronization for some sequences of method calls, to prevent other threads from cutting in between method calls. For such classes, I believe the original synchronization of each method was largely useless and misleading. If I need to use a List in a thread-safe manner I will probably use a simple ArrayList and do all synchronization externally. Using Vector or Collections.synchronizedList() has a bad tendency to make people think they're safe, when they're really not.

3. That's a very very general question, and without knowing how much you already understand about the subject, it's best answered by a tutorial, as Edward suggested.

[palla sridhar]

Hey Jim!!
W.r.t to the 2nd answer

Sometimes, in poorly-designed not-really-thread-safe classes like java.util.Vector and its evil twin Collections.synchronizedlist(), you may need additional synchronization for some sequences of method calls, to prevent other threads from cutting in between method calls. For such classes, I believe the original synchronization of each method was largely useless and misleading.

if you need additional synchronization between method calls, what's the use of those synchronized methods.?

Is it the same case with all the synchronized methods for like StringBuffer etc?

Please reply!!

[Jim Yingst]

As I said, for such classes, I believe the synchronization of each method is largely useless and misleading. I mean, it's possible to use them, and just add some extra synchronized blocks where necessary, but it's more confusing when the class does some of the synchronization you need, but not all of it.

[palla]: Is it the same case with all the synchronized methods for like StringBuffer etc?

It varies from class to class. Some are well-designed for thread safety, and some aren't. I believe that the synchronization in StringBuffer is just as useless as the synchronization in Vector - I would almost always require more synchronization to do something thread-safe. In comparison, Hashtable's synchronization is somewhat more useful, because there are at least some useful tasks that I can do with a Hashtable in a thread-safe manner without any additional synchronization at all. However there are still some tasks that do require additional synchronization. Compare Hashtable to ConcurrentHashMap, which has a richer set of useful atomic operations. (ConcurrentHashMap doesn't actually use synchronization at all; it uses other tricks. But that's an implementation detail - it could have used synchronization internally to achieve the same functionality.)