Win a copy of Java 9 Modularity: Patterns and Practices for Developing Maintainable Applications this week in the Java 9 forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

CanThread inside synchronized method or a block release CPU without using wait?volatile in Singleton  RSS feed

 
sat kadam
Greenhorn
Posts: 15
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Q1) Can one thread running inside a synchronized method or a block release cpu without using wait?

Q2)I am trying to understand Double check locking in singleton pattern.


Please correct my understanding
As per my understanding suppose  if Thread T1 is inside the synchronized block after acquiring lock and before it creates the instance it loses the CPU.While other Thread T2 sees the instance as a null by the time Thread1
wake up and creates the instance and release the lock.But for Thread 2 it is still null.Now it acquires the lock and creates another instance.Now both the Threads T1 and T2 creates separate instances.

To avoid this,Singleton _instance is made volatile so that when Thread 1 creates the instance and it immediately  updates its state to Main Memory.
Volatile also forces Thread2 to read the value from Main Memory instead accessing from Local Cache.

 
Stephan van Hulst
Saloon Keeper
Posts: 7927
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
sat kadam wrote:Q1) Can one thread running inside a synchronized method or a block release cpu without using wait?

Sure. One example is trying to enter a synchronized block while another thread already owns that block's lock.

While other Thread T2 sees the instance as a null by the time Thread1
wake up and creates the instance and release the lock.But for Thread 2 it is still null.Now it acquires the lock and creates another instance.

Even if T1 stops running while it's inside the synchronized block, T2 can not enter the synchronized block until after T1 has resumed and exited the synchronized block. Afterwards, _instance will not be null, T2 will perform the second check and notice that it doesn't have to create a new instance.

Note that the double checked locking mechanism only marginally improves performance over just synchronizing the entire method body, because accessing a volatile field still incurs some synchronization costs.

Besides the fact that you probably have no reason to use the Singleton pattern for an object that is expensive to construct, it definitely shouldn't be accessed from a static context, and have it loaded lazily.

Learn the double checked locking pattern if it interests you, but never use it. It's dumb, it's broken half of the time, and it reeks of bad program design.
 
Henry Wong
author
Sheriff
Posts: 23289
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stephan van Hulst wrote:
sat kadam wrote:Q1) Can one thread running inside a synchronized method or a block release cpu without using wait?

Sure. One example is trying to enter a synchronized block while another thread already owns that block's lock.


Another is a call to a blocking queue that is full. Or to a file, when the disk is busy. Or to a socket, when the network is busy. etc. etc. etc.... basically, anything that takes the thread out of the runnable state. A thread can't be running, if it is not runnable.

... regardless, with all of these examples, it will *not* release the synchronized lock, as the wait() method will also do.

Henry
 
Don't get me started about those stupid light bulbs.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!