• Post Reply Bookmark Topic Watch Topic
  • New Topic

Method Synchronization in Non-Singleton Object  RSS feed

 
Livingston Putla
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Paul Clapham
Sheriff
Posts: 22841
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Livingstone, welcome to the Ranch!

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.

 
Livingston Putla
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

Example
class Hashtable extends..............
{
private Hashtable(){}

public static Hashtable getInstance()
{
}

}
 
Paul Clapham
Sheriff
Posts: 22841
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Livingston Putla wrote:If synchronzid methods make sense ONLY for singleton objects...


But they don't. They can be used with any objects.
 
Livingston Putla
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wondering the reason why Java community made Hashtable as non singleton object but synchronzied methods...what good does it make....
 
Paweł Baczyński
Bartender
Posts: 2087
44
Firefox Browser IntelliJ IDE Java Linux Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The synchronization is needed when two or more threads share the same instance. It doesn't matter how many instances of the class exist. So, it doesn't matter whether the class is singleton or not.

It is perfectly fine to create a Hashtable instance and share it with many threads.

Why do you assume only singletons can be shared between threads?
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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

Example
...

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.
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!