What is that purpose of having synchronized methods in non-singleton object...?
i understand that synchronization is needed when more than one thread share an object inorder to update the state of the object in anyway . But if those threads get their own copy of underlying object..then i think there is no need for synchronizing methods.
Ex : Hashtable ht=new Hashtable();
In mutithreaded envinronment , Lets say Thread1 and Thread2 encounters above statment, then both the threads gets its own instance of hashtable whichmeans both the threads have nothing to communicate as they got their own copy of hastable.
So in this context , i dont see the necessity of synchronziation in Hashtable.
I agree synchronization methods make sense for singleton objects....in this case , same object is shared by more than one thread.
In the particular context you described, where two threads create two objects (of the same type), there's certainly no need to synchronize that operation. There's no scenario there where two threads are sharing an object.
But you also said
i understand that synchronization is needed when more than one thread share an object inorder to update the state of the object in anyway .
And that says it all. Synchronization is needed when two or more threads share an object and the object is being updated by at least one of them. Do you see anything in that description which says "But then synchronization is not actually needed if another object of that type happens to exist"? No: the existence of other objects has nothing to do with that scenario.
posted 10 months ago
If synchronzid methods make sense ONLY for singleton objects, then I'm wondering why Hashtable's constructor is NOT made private and exposed the creation only thru static means like below
class Hashtable extends..............
Livingston Putla wrote:If synchronzid methods make sense ONLY for singleton objects, then I'm wondering why Hashtable's constructor is NOT made private and exposed the creation only thru static means like below
What good is that going to do when concurrent access is involved? I think you're confused about the underlying reasons for needing synchronization. It's really about mutable and shared members (fields) of a class.
It's not about an object being a Singleton or not. In fact, a Singleton that is not mutable is also thread-safe.
I think you may have read a statement like "Concurrent access to a Singleton needs to be synchronized" and missed the nuances involved.
Some things that you need to watch for with regard to synchronization. Note that when I say "access" below, I mean "concurrent access":
1. Mutability - access to anything that's mutable may need to be synchronized
2. Fields - access to mutable instance or class member variables may need to be synchronized
3. Thread-safety - if a class is not documented as being thread-safe, then you may need to synchronize access to instances of that class and/or to static members of that class.
Local variables are thread-safe but note that if you are assigning values to/from fields/values that are not thread-safe, the thread-safety of a local variable doesn't extend to cover those so you still need to watch out for concurrency issues.
Parameters are generally thread-safe because of Java's pass-by-value semantics. However, if you're dealing with a reference to a mutable object, you also need to trace back up the call stack and make sure the reference value passed is either a local variable or a method parameter (in which case, you have to trace back up again and keep going until you understand how it was created).
Bottom line: Synchronization is not about being a Singleton; Singleton only raises the danger of there being concurrency issues when the instance is accessed and mutated. Synchronization is required for any mutable value, typically an instance or class member variable, that can be read and modified by different threads at virtually the same time.
Practice only makes habit, only perfect practice makes perfect.—every music teacher ever
Practice mindfully by doing the right things and doing things right.— Junilu