Why I'm not able to achieve Synchronization on this below piece of program:
class P
{
synchronized void pp(String s)
{
System.out.println (s);
}
}
class threadA extends Thread
{
P ob;
String s;
threadA (P ob, String s)
{
this.ob = ob;
this.s = s;
}
public void run ()
{
for (int i=1;i<=5;++i)
{
ob.pp (s);
try
{
Thread.sleep (1000);
}
catch (Exception e) {}
}
}
}
class gain
{
public static void main(String[] args) {
P ob = new P ();
threadA a = new threadA (ob,"Hello User");
threadA b = new threadA (ob,"Bye User");
a.start();
b.start();
}
}
OP:
Hello User
Bye User
Hello User
Bye User
Bye User
...
I want OP in the form of:
Hello User
Hello User
Hello User..
Bye User
Bye User
Bye User..
or my concept of synchronization is wrong?
You cannot do such synchronization from P class. What happens now is that any calls to pp() is blocked if another thread is currently executing the method. As long as the method ends (which is quick if you are just going to print things to the console), the next thread would be allowed to enter the method.
What you are trying to achieve is not possible, unless both the threads are aware of each other and communicate with each other. In other words, when the first thread finishes what it needs to do, it should explicitly inform the second thread to start. This is effectively executing sequentially, instead of parallelly.
Update
You wanted to visualize what is happening so I'll do it here.
You created 2 threads.
You start the first thread.
The first thread starts to run, while some time later the second starts to run as well.
When your first thread runs, it goes to the for loop. Then it calls P.pp().
When P.pp() is called from first thread, it locks the P object.
Since the method is so short, it is going to exit very quickly.
When the method exits, it releases the lock on P.
If your second thread reaches the synchronize block before the first thread exits, it will wait (blocked).
When the first thread exits, the second thread enters as the first thread releases the lock.
The first thread returns to the loop and try to call P.pp() again.
This will continue, depending on which thread is faster, the order of execution would be different.
Synchronized keyword means that two threads on that code block have to respect the order they tried to access that block code. It doesn't mean that the execution flow is serialized.
To have what you want try to put the for inside the synchronized block...
You should try something like this
class P
{
void pp(String s)
{
System.out.println (s);
}
}
class threadA extends Thread
{
P ob;
String s;
threadA (P ob, String s)
{
this.ob = ob;
this.s = s;
}
public void run ()
{
for (int i=1;i<=5;++i)
{
synchronized(ob)
{
ob.pp (s);
try
{
Thread.sleep (10);
}
catch (Exception e) {}
}
}
}
}
public class gain
{
public static void main(String[] args) {
P ob = new P ();
threadA a = new threadA (ob,"Hello User");
threadA b = new threadA (ob,"Bye User");
a.start();
b.start();
}
}
i.e while sleeping keep thread synchronized so that you get required output or else you are not sure which thread might come up first after sleep. See this
can u explain me the flow of control of my program?
"Hello" starts and run through the loop until it reaches the synchronized method
"Bye" does the same.
"Hello" is the first to acquire the lock.
"Bye" blocks waiting for the lock.
"Hello" executes the method and releases the lock.
"Bye" can now acquire the lock and "Hello" has released it
"Bye" can now execute the method, and releases the lock as "Hello" did.
what can I do so that hello after executing the method goes to blocked pool and also doesn't leaves the lock for bye to acquire it
Hold the lock, and don't release it if you want to retain it.
public void run() {
synchronized(ob); { // hold the lock the whole time
for (int i = 1; i <= 5; ++i) {
ob.pp (s);
try { Thread.sleep(1000); } catch (Exception e) {}
}
} // releases the lock here.
}
Related
I'm looking at some notify/wait examples and came across this one. I understand a synchronized block essentially defines a critical section, but doesn't this present a race condition? Nothing specifies which synchronized block is entered first.
public class ThreadA {
public static void main(String[] args){
ThreadB b = new ThreadB();
b.start();
synchronized(b){
try{
System.out.println("Waiting for b to complete...");
b.wait();
}catch(InterruptedException e){
e.printStackTrace();
}
System.out.println("Total is: " + b.total);
}
}
}
class ThreadB extends Thread {
int total;
#Override
public void run(){
synchronized(this){
for(int i=0; i<100 ; i++){
total += i;
}
notify();
}
}
}
Output per website:
Waiting for b to complete...
Total is: 4950
Right, it's not guaranteed which thread will execute first. The thread b could do its notification before the main thread ever starts to wait.
In addition to that, a thread can return from wait without having been notified, so setting a flag and checking it before entering the wait technically isn't good enough. You could rewrite it to something like
public class ThreadA {
public static void main(String[] args) throws InterruptedException {
ThreadB b = new ThreadB();
b.start();
synchronized(b){
while (!b.isDone()) {
System.out.println("Waiting for b to complete...");
b.wait();
}
System.out.println("Total is: " + b.total);
}
}
}
class ThreadB extends Thread {
int total;
private boolean done = false;
#Override
public void run(){
synchronized(this){
for(int i=0; i<100 ; i++){
total += i;
}
done = true;
notify();
}
}
public boolean isDone() {return done;}
}
so that the main thread will wait until b is done with its calculation, regardless who starts first.
By the way, the API documentation recommends you not synchronize on threads. The JDK synchronizes on threads to implement Thread#join. A thread that terminates sends a notifyAll that anything joining on it receives. If you were to call notify or notifyAll from a thread you've acquired the lock on, something joining on it could return early. One side effect of this here is that if you remove the notify the code works the same way.
Yes, it's a race condition. Nothing prevents ThreadB from starting, entering its run method, and synchronizing on itself prior to ThreadA from entering its synchronized block (thus waiting indefinitely). However, it's very unlikely to ever happen, considering the time it takes for a new thread to begin execution.
The easiest, and most recommended way to handle this type of situation is to not write your own implementation, but opt to use a callable/future provided by an Executor.
To fix this particular case without following standards:
Set a boolean 'finished' value set at the end of ThreadB's synchronized block.
If the boolean 'finished' is true after entering the synchronized block, then you should not call wait.
Yes - it is a race as to which thread enters which synchronized block first. For most scenarios of the race, the output and the answer will be the same. For one, however, the program will deadlock:
Main starts calls b.start() and immediately schedules out.
Thread B starts, enters synchronized, calls notify().
Main enters its synchronized block, calls wait()
In this case, main will wait forever since thread b called notify before main blocked on wait().
That said, this is unlikely - but with all threading you should conclude that it will happen and then at the worst possible time.
For the code below, the expected output is:
Waiting for b to complete...
Total is: 4950
How come it can't print the Total is.. first then Waiting for b.. after? I'd think b.start() could be executed first in some cases, then it holds onto ThreadB's lock with synchronized(this) in ThreadB.run() thus blocking main from entering in synchronized(b).
Is anything wrong with what I just stated?
public class ThreadA {
public static void main(String[] args) {
ThreadB b = new ThreadB();
b.start();
synchronized(b) {
try{
System.out.println("Waiting for b to complete...");
b.wait();
} catch(InterruptedException e) {
e.printStackTrace();
}
System.out.println("Total is: " + b.total);
}
}
}
class ThreadB extends Thread {
int total;
#Override
public void run() {
synchronized(this) {
for(int i=0; i<100 ; i++) {
total += i;
}
notify();
}
}
}
The two output statements will always have the same order, because they are executed on one thread. Waiting for another thread to finish between them will not change their execution order.
If you put the "Total is ..." output to the end of b's run() then there might be a chance for seeing indeterministic orders of the outputs.
EDIT - Please also note #Holger 's comment to this answer:
[...] in the unlikely, but still possible case that ThreadB’s synchronized block is executed first, its notify() call will have no effect as no-one is waiting yet and then, ThreadA’s wait() call may hang forever as there will be no subsequent notification.
Actual problem over here is you have only one thread "b" over here and you are calling wait() on b which is taking b thread to WAIT state and there is no other thread which can notify this thread and bring b back to runnign state.
I am trying to achieve this: Created two different threads, one prints odd numbers, one prints even numbers. Once one thread prints a number, it has to wait for the other thread and so on, that is one-after-other.
To achieve this, i am using synchronized block along with wait() and notify().
I am creating a class whose's object will be used to pass to synchronized block in both the threads.
Here is the code:
--> This is used object which will be passed to synchronized block.
package com.vipin.multithread.variousdemos;
public class SyncObject {
public SyncObject () {
}
}
Odd Thread:
package com.vipin.multithread.variousdemos;
public class OddThread implements Runnable {
private Thread t;
int index=0;
SyncObject so=null;
int odd_nums[] = {1,3,5,7,9};
public OddThread(SyncObject so) {
t = new Thread(this,"Odd Thread");
this.so = so;
t.start();
}
public Thread getThreadInstance() {
return t;
}
#Override
public void run() {
while (true) {
synchronized(so) {
System.out.println("Odd num is --->" + odd_nums[index]);
try {
so.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
index++;
so.notify();
if(index>=5) {
return;
}
}
}
}
}
Even Thread: UPDATE
package com.vipin.multithread.variousdemos;
public class EvenThread implements Runnable {
private Thread t;
int index=0;
SyncObject so=null;
int even_nums[] = {2,4,6,8,10};
public EvenThread(SyncObject so) {
t = new Thread(this, "Even thread");
this.so = so;
t.start();
}
public Thread getThreadInstance() {
return t;
}
#Override
public void run() {
while(true) {
synchronized(so) {
System.out.println("Even num is --->" + even_nums[index]);
so.notify(); <-- Here we are notifying.
try {
so.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
index++;
//so.notify(); <-- commented out.
if(index>=5) {
break;
}
}
}
}
}
Main Application:
package com.vipin.multithread.variousdemos;
public class EvenOddDemo {
public static void main(String[] args) throws InterruptedException {
SyncObject so = new SyncObject();
OddThread ot = new OddThread(so);
EvenThread et = new EvenThread(so);
System.out.println("\nIn main thread");
Thread.sleep(1000000000);
System.out.println("Exiting main thread...");
}
}
---> As seen in the code, I am creating two threads to print even and odd numbers. I am using synchronized block, and passing object of type ==> SyncObject.
SyncObject I am passing as argument to these different threads in main.
However, this programs halts, i.e stuck only first statement gets executed, and then it waits forever:
Here is the output:
Odd num is --->1
In main thread
Even num is --->2
I am not able to understand why this program waits for ever, I am using SAME object on which we are invoking synchronized(), wait() and notify(). As per my understanding, it should work, not sure why this is not working.
Any clues as to why this is waiting forever.
UPDATE:
I did some changes in the code, UPDATE and it works fine.
I still have some doubt. Does notify() be called by the thread even if it has not locked the monitor, like in my case after i updated the code.
Sequence of events:
Odd thread gets executed first, then it calls wait() <-- it releases the monitor and now in sleep mode.
Even thread runs, prints msg, and calls notify() <-- here i am not having clear understanding.
When Even thread calls notify(), at that point it has the monitor, so when it calls notify(), does is still own the monitor?
Now, after Even thread calls notify(), then Odd thread gets notified, and hence it starts execution from the point it was sleeping. It is doing some execution and calls notify(), at that points I presume Odd thread is NOT owning the monitor, it calls notify(). So, my question is, does notify() work same whether or not the thread owns the monitor?
It is only when one do the code, one really understands this. I read book and i felt i understood everything, and seems i am back to square one!
The problem here is simply that both threads go straight into wait. Thread 1 gets so, prints value then waits. Thread 2 then gets so, prints value then waits. So both are sleeping away, since nobody is there to notify them. So, a simple fix would be to do so.notify(), right before so.wait(). Then they're not infinitely waiting.
EDIT
Odd thread starts, executes & then waits. Then even thread starts, executes, notifies & then waits. Even thread holds the lock over the monitor until it goes into wait.
When the even thread called on notify, the odd thread awakens & polls for the lock. Once the even thread goes into wait (& releases the lock), then the odd thread can obtain the lock.
If the even thread had not called on notify, then the odd thread would continue to sleep. The even thread would have gone to wait & released the lock. No thread is polling or attempting to obtain the lock, hence the program remains in the suspended state.
The documentation also provides a similar explanation. I hope that clears your doubts.
Can anyone explain this program on inter-thread communication?
// A correct implementation of a producer and consumer.
class Q {
int n;
boolean valueSet = false;
synchronized int get() {
while(!valueSet)
try {
wait();
} catch(InterruptedException e) {
System.out.println("InterruptedException caught");
}
System.out.println("Got: " + n);
valueSet = false;
notify();
return n;
}
synchronized void put(int n) {
while(valueSet)
try {
wait();
} catch(InterruptedException e) {
System.out.println("InterruptedException caught");
}
this.n = n;
valueSet = true;
System.out.println("Put: " + n);
notify();
}
}
class Producer implements Runnable {
Q q;
Producer(Q q) {
this.q = q;
new Thread(this, "Producer").start();
}
public void run() {
int i = 0;
while(true) {
q.put(i++);
}
}
}
class Consumer implements Runnable {
Q q;
Consumer(Q q) {
this.q = q;
new Thread(this, "Consumer").start();
}
public void run() {
while(true) {
q.get();
}
}
}
class PCFixed {
public static void main(String args[]) {
Q q = new Q();
new Producer(q);
new Consumer(q);
System.out.println("Press Control-C to stop.");
}
}
Output
Put: 1
Got: 1
Put: 2
Got: 2
Put: 3
Got: 3
Put: 4
Got: 4
......
It is very confusing as far as I am concerned, especially the put and get methods where notify() and wait() are used. Please also explain why a boolean value is used.
So there are 2 threads. Qne is setting values on this Q data structure and the other is reading them. Q uses a boolean flag to tell whether a new value is present, the flag gets cleared once an existing value is read.
Q.get uses wait to block until a new value is available to read. Once it's read the new value it sets the flag back to false.
Q.put waits until the other queue has read the new value before setting it to a new value, then lets the other thread know by setting the boolean flag and calling notify.
Remember that wait gives up the lock so the other thread can acquire it.
The boolean flag is needed because a thread may stop waiting without having been notified. Just because a thread woke up doesn't mean it got a notification. Also, even if the thread gets notified, since the thread gave up the lock when it started to wait, the current state of things is unknown (in general there are multithreaded programs where another thread might sneak in and snag something between the time a thread is notified and the time it can regain the lock) so the thread has to re-test the condition again once it has the lock.
Constructs like wait and notify are building blocks for large concurrent programs, so some things may not make as much sense in a small example with only two threads.
See basically its a multithreaded communication with synchronized methods.
simple rquirement here is
1)first allow to write for producer.
2)next allow to read for consumer.
that is controlled using boolean flag valueSet.
in case of producer means put method of Q, logic works this way
if the valueSet is is true means already write is done then ask put method called thread to wait. so it goes to wait until someone calls notify.
ofcourse it wont continue further logic and keeps on waiting for someone to call notify.
coming to reader means get() of Q,
if the valueSet is is false means writter is executing then ask get method called thread to wait. so it goes to wait until someone calls notify.
so once writer completes the execution it calls notify at the end and now reader threads awake and starts reading.
I am trying to understand synchronization in JAVA. I have written a small program.
class A implements Runnable {
public void run() {
Random r = new Random();
int i = r.nextInt(10);
if(i<5){
print();
}else{
display();
}
}
public synchronized void display()
{
System.out.println("display");
print(); // Line no: 19
}
public synchronized void print()
{
System.out.println("print");
}
}
public class Test {
public static void main(String argv[]) throws Exception {
A a = new A();
Thread t = new Thread(a, "A");
Thread t1 = new Thread(a, "B");
t.start();
t1.start();
}
}
Consider 1st case: I have put a debug point on the 1st line inside print method.
Now when thread A starts running and number randomly generated number 1.
It will call print method and as I have debug point on its first line. It will wait for me to resume.
Now during that time, thread B starts running and number randomly generated number 8.
It should call display method but I see the execution doesn't go inside the display method. It will go inside only after I have make sure that thread A has finished execution.
Shouldn't thread B should go inside display method and wait on the line no 19.
Can two thread generated by same object cannot execute 2 different synchronized method?
Please explain.
To enter a synchronized method of an object, the thread must acquire the intrinsic lock associated with that object. The lock is bound to the object. Each method doesn't have its own lock.
Since thread A is inside a synchronized method of your Runnable, the other thread must wait for the lock to be released before being able to enter a synchronized method, whether the method is the same or not.