1

First off I need to clear something basic, assume I have a synchronized block or a synchronized method and one thread already entered the synchronized part and 5 new threads try to access the synchronized part, will they stop running until the first thread leaves the synchronized part? and if they do, will they wait in a prioritized queue?

Second question is regarding monitors, assume I have a the following code:
synchronized(someObject){ //do some stuff someObject.wait(); } Is it correct to assume that if a thread runs this code while another thread is waiting on the monitor and then the first thread calls wait, the second thread will enter the code block (I.E. the wait releases someObject's monitor) ?

And last question is regarding a Singleton implementation, in order to make it thread safe is it enough to synchronize the instantiation line inside the singleton class to make sure it never gets called more than once ? and if so, is this the best practice ?

Metaldream
  • 125
  • 1
  • 1
  • 9

1 Answers1

2

First off I need to clear something basic, assume I have a synchronized block or a synchronized method and one thread already entered the synchronized part and 5 new threads try to access the synchronized part, will they stop running until the first thread leaves the synchronized part? and if they do, will they wait in a prioritized queue?

If one thread has a lock on the monitor other threads cannot acquire the same lock on the same object. Therefore, they will blocked. Once the current thread has relinquished its lock, another thread may then acquire the lock. In terms of priority, even if one thread has a higher priority than another, there is no guarantee the higher priority thread will run before a lower priority one.

The ReentrantLock class constructor offers the possibility of creating a fair lock or a non-fair lock. In the fair scenario, threads acquire the lock on the object in the order they requested it. In the non-fair scenario, barging of requests is allowed where one request may barge itself higher up the request queue.

Second question is regarding monitors, assume I have a the following code:

synchronized(someObject){
        //do some stuff
        someObject.wait();
}

Is it correct to assume that if a thread runs this code while another thread is waiting on the monitor and then the first thread calls wait, the second thread will enter the code block (I.E. the wait releases someObject's monitor) ?

When wait is called by the current thread, the current thread will release all locks it has on the object. Once that lock is released, other threads may attempt to acquire the same lock on the same object.

And last question is regarding a Singleton implementation, in order to make it thread safe is it enough to synchronize the instantiation line inside the singleton class to make sure it never gets called more than once ? and if so, is this the best practice ?

See this post regarding thread safe singleton classes.

Community
  • 1
  • 1
  • Great answer. You might also add the fact that somebody could control thread-locking fairness using a [ReentrantLock](http://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/ReentrantLock.html) instead of the classical synchronized keyword. – Edwin Dalorzo May 02 '15 at 13:47
  • Thanks for the quick answer! made everything clear and to the point. – Metaldream May 02 '15 at 14:02