I have this piece of code:
Profile a = randomProfile();
Thread workerA = new Thread(new Downloader(a));
workerA.start();
Profile b = randomProfile();
Thread workerB = new Thread(new Downloader(b));
workerB.start();
synchronized (workerA) {
try {
workerA.wait();
} catch (InterruptedException e) {
System.out.println("Error on background thread!");
System.exit(1);
}
}
synchronized (workerB) {
try {
workerB.wait();
} catch (InterruptedException e) {
System.out.println("Error on background thread!");
System.exit(1);
}
}
And a Downloader class which implements the Runnable interface, and its run() method looks like:
#Override
public void run() {
synchronized (this) {
//work...
notify();
}
}
Now this is working as intented, sometimes. Most of the time though, it seems to get stuck in the second synchronized block (it always gets through the first one).
Am I doing something wrong?
Also do I have some conceptual error, e.g. this implementation doesn't give me any advantage over a single thread?
The wait() is invoked on the Thread objects but the notify() is invoked on the Downloader objects.
The background threads should therefore run without a problem (although completely unsynchronized), and the main thread should always block to infinity in the first synchronized block because there's no-one to wake it up.
Where this case is special is that you invoked wait() on the Thread objects themselves, which is discouraged (and by this I really mean: forbidden). When a thread terminates, it invokes notifyAll() on itself, so when workerA finishes, you get out of the first synchronized block. But by the time the second synchronized block is reached, workerB is already finished, so the second wait() will never end.
Whether there is a conceptual error depends on what you were trying to achieve. From the code it looks very much like what you tried to do is join() the background threads.
Related
I've seen a lot of example for wait and notify, but still I have a problem.
public class Main(){
public static void main(String args[]) throws Exception {
MyThread s = new MyThread();
s.start();
}
}
class MyThread extends Thread {
public void run() {
k();
}
public synchronized void k() {
System.out.println("before wait");
try {
wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
System.out.println("do something after wait");
}
public synchronized void m() {
for (int i=0;i<6;i++)
System.out.println(i);
notify();
}
}
The only output I get when run the program is: "before wait".
The thread you create in main invokes MyThread#k() which goes into a wait. At that point, that thread will do nothing else until it is awakened or interrupted. But the only place in your code where it could possibly be awakened is the notify in MyThread#m(). Since nothing in your program calls that method, the thread can never be awoken.
What you probably want is to add a call to s.m() right after s.start() in your main program. That way your main thread will execute the notify that's needed to wake up your thread.
Unfortunately, that's very unlikely to work. The problem is that s.start() causes your created thread to become ready to run, but it doesn't necessarily run immediately. It could well happen that your call to s.m() will complete before the created thread does anything. And then you'll still have exactly the same result as before, except that you'll see the integers 0..6 printed out before before wait. The notify will do nothing, because the child thread has not yet performed its wait. (And by the way, since both MyThread#k() and MyThread#m() are both synchronized, increasing your loop limit in MyThread#m() won't change a thing... the child thread won't be able to enter MyThread#k() while MyThread#m() is running. You could improve that by putting the notify in a sycnchronized block rather than making all of MyThread#m() synchronized.)
You can try to get around this by adding Thread.sleep(1000) before s.m() in your main program. That will almost certainly work because your main thread will yield execution, giving your JVM the opportunity to schedule the child thread for some useful work. By the time the main thread wakes out of its sleep and performs its s.m() call, the child will probably have executed its wait and you will then see your do something after wait message.
But that's still pretty crummy, because it still depends on scheduling events that you don't really have any control over. There's still no guarantee that the wait will happen before the notify.
This is why when using wait/notify you should generally arrange for there to be some sort of reliable test as to whether whatever you're waiting to be done has actually occurred. This should be a condition that, once it turns turns true, will remain true at least until the test has been subsequently performed. Then your typical wait loop looks something like this:
while (!isDone()) {
synchronized(monitorObject) {
try {
monitorObject.wait();
} catch (InterruptedException e) {
}
}
}
Putting the whole thing in a loop takes care of premature waking, e.g. due to InterruptedException.
If the required work has already occurred by the time this code is executed, no wait occurs, and the notify executed by the code that did the work was a no-op. Otherwise, this code waits, and the code completing the work will eventually do a notify which will wake this code up as required. Of course, it's critical that, at the time the notify is performed, the wait condition (isDone() above) be true and remain true at least until tested.
Here's a corrected version of your code that incorporates a proper wait loop. If you comment out the Thread.sleep() call, you will likely not see the waiting message, because the work will complete before the wait loop even starts. With the sleep included, you'll probably see the waiting message. But either way, the program will work properly.
public static void main(String[] argv) throws Exception {
MyThread s = new MyThread();
s.start();
Thread.sleep(1000);
s.m();
}
class MyThread extends Thread {
#Override
public void run() {
k();
}
private boolean done = false;
public void k() {
System.out.println("before wait");
while (!done) {
System.out.println("waiting");
synchronized (this) {
try {
wait();
} catch (InterruptedException e) {
}
}
}
System.out.println("do something after wait");
}
public void m() {
for (int i = 0; i < 6; i++) {
System.out.println(i);
}
synchronized (this) {
done = true;
notify();
}
}
}
The problem is, that you're not calling your m method, so notify is never called, so your thread sleeps forever. You could call it in main, after the start, using s.m():
MyThread s = new MyThread();
s.start();
s.m();
Maybe you should sleep for a little time before calling the m method, as it could run sooner than k in the thread:
s.start();
try {
Thread.sleep(200);
} catch (InterruptedException e) {
// nothing to do
}
s.m();
Not closely related to the question, but a throws declaration in main is not very advisable, even a generated printStackTrace is better than throwing the exception away.
Pretty much all resources I've found on synchronized blocks use this or a member of the class as a lock object. I'm interested in finding out why I can't get synchronized blocks to work when the lock object is a (static) member of another class. Here's my code to illustrate the problem:
public class Test {
public static void main(String[] args) {
Thread thread1 = new FirstThread();
Thread thread2 = new SecondThread();
thread1.start();
thread2.start();
}
}
class FirstThread extends Thread {
#Override
public void run() {
synchronized (Lock.lock) {
System.out.println("First thread entered block");
try {
Lock.lock.wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
System.out.println("First thread exited block");
}
}
class SecondThread extends Thread {
#Override
public void run() {
try {
Thread.sleep(1000); //just making sure second thread enters synch block after first thread
} catch (InterruptedException e) {
e.printStackTrace();
}
synchronized (Lock.lock) {
System.out.println("Second thread entered block");
Lock.lock.notifyAll();
}
System.out.println("Second thread exited block");
}
}
class Lock {
public static Object lock = new Object();
}
My understanding is that the second thread should not be able to enter the synchronized block until the first thread exits, since they are synchronized on the same object. Thus I was expecting the program to hang (deadlock?) after "First thread entered block", since the second thread can't enter the block and the first thread will be stuck waiting for a notification. But instead I got the following output:
First thread entered block
Second thread entered block
Second thread exited block
First thread exited block
Clearly the second thread enters the synchronized block before the first thread has left it's block. Can someone explain what I'm missing?
I thought the purpose of synchronized blocks was to prevent exactly this. Is it because the lock object is a member of another class?
first thread Lock.lock.wait() relinquish the lock on the synchronized object so other thread can enter the critical path and wake up the waiters.
note that sleep(), instead, does not.
Difference between wait() and sleep()
Quote from the javadoc of Object.wait():
The thread releases ownership of this monitor and waits until another thread notifies threads waiting on this object's monitor to wake up either through a call to the notify method or the notifyAll method.
If that was not the case, waiting would systematically cause a deadlock, since no thread would ever be able to enter the synchronized section needed to call notify() or notifyAll(), making wait and notify completely useless.
When you call lock.wait you "release ownership of this monitor". This allows thread 2 to enter the synchronized block.
Consider there are two threads which are waiting to execute synchronized block. Now one get chance one is waiting in this case do I really need to call notify() ? I think as synchronized block execution completes other thread will release the lock ? what is the exact use of notify() method ?
Threading experts please explain ?
No, you wouldn't need to use notify() in that case. You are correct, the thread that had to wait to acquire the lock would automatically proceed after the lock was released.
The notify() method works in conjunction with the wait() method. When one thread invokes wait(), it may release the lock and begin waiting. One of the conditions that can end the wait is when another thread invokes notify(). Both wait() and notify() must be invoked on an instance on which the current thread is synchronized.
This can be used, for example, to create a channel between two threads, where one thread is consuming information produced by another. If the consumer runs out of information to process, it might wait() until the producer does a notify() that more data are available.
When a thread enter synchronized block and calls wait the lock acquired while entering the synchronized block is released and the thread waits for other thread to notify it in which case it will reacquire the lock and proceed.Lock is again released when the thread comes out of the synchronized block.
from the doc,
Wakes up a single thread that is waiting on this object's monitor. If
any threads are waiting on this object, one of them is chosen to be
awakened. The choice is arbitrary and occurs at the discretion of the
implementation. A thread waits on an object's monitor by calling one
of the wait methods.
so if an object is waiting by calling a wait method. then you can awake them using notify.
Description
The java.lang.Object.notify() wakes up a single thread that is waiting
on this object's monitor. If any threads are waiting on this object,
one of them is chosen to be awakened. The choice is arbitrary and
occurs at the discretion of the implementation. A thread waits on an
object's monitor by calling one of the wait methods.
For more information refer below links.
notify()
Documentation
Doc
I hope it will help you.
Like if you are using Multiple threads the method is synchronized which means it will share among all the threads but any thread will use it after the execution another thread.
and if there is any change is made by any thread then it will visible for all by using notify method below code is example for that:
class Detail {
public String name = "", sername = "";
Scanner sc;
public synchronized String getData() {
try {
wait();
} catch (InterruptedException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return name+""+sername;
}
public synchronized void show() {
try {
name = "hello";
sername = "hii";
Thread.sleep(1000);
} catch (Exception e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
notify();
}
}
class Data1 extends Thread {
Detail detail;
public Data1(Detail detail1)
{
// super("1");
this.detail = detail1;
start();
}
public void run()
{
System.out.println("name is :"+detail.getData());
}
}
class Data2 extends Thread {
Detail detail2;
public Data2(Detail detail1)
{
//super("2");
this.detail2 = detail1;
start();
}
public void run()
{
detail2.show();
}
}
public class SyncDemo {
public static void main(String ar[])
{
Detail det = new Detail();
Data1 d1= new Data1(det);
Data2 d2= new Data2(det);
}
}
I'm developing an Android app.
I have two threads. The first one has to wait the second one.
I have this code on the first thread run method:
#Override
public void run() {
synchronized (this.secondThread) {
this.secondThread.wait();
}
[...]
}
And on my second thread:
#Override
public void run() {
synchronized (MyClass.myLock) {
try {
// Do something important here
}
catch (Exception ex)
{
// manage exception
return;
}
finally {
// do something...
}
}
synchronized (this) {
this.notify();
}
[...]
}
As you can see, there is a return inside catch block.
With this code, will first thread get notified if an exception occurs on the second thread?
will first thread get notified if an exception occurs on the second
thread?
Answer is no. Unless you explicitly notify() in catch block before returning, the other thread will not wake up
Answer is no. In order to get both notify the has to be synchronized on the same object. this can be different. If you want all the thread waiting on a object to be notify you havo to call notifyAll() instead of notify(). The notifyAll() should be put inside the finally block. Infact despite the return the finally block is alway executed
The notify() should be inside the finally block if you want it to work unconditionally, but you should really be using Thread.join() instead of wait(): then the thread being waited on doesn't have to do anything at all.
Answer is no. Unless you explicitly notify() in catch block before returning, the other thread will not wake up, You have to Al possible exceptions and in every case notify to your first thread, make sure that your first thread input is not dependent on second thread output otherwise you may phase some other problem in thread 1.
I have a method which uses CyclicBarrier as shown below:
public void getMessage(Message obj){
CyclicBarrier barrier = new CyclicBarrier(1, new Runnable() {
#Override
public void run() {
synchronized(obj){
System.out.println("--The End --");
}
}
});
executor.execute(new Runnable() {
#Override
public void run() {
synchronized(obj){
//Perform some routine with message object
}
try {
barrier.wait();//java.lang.IllegalMonitorStateException thrown on this line
} catch (InterruptedException e) {
e.printStackTrace();
}
}
});
}
At the point where i wait for the routine to finish executing, i get:
Exception in thread "pool-2-thread-3"
java.lang.IllegalMonitorStateException
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
Do anyone knows what I am doing wrong here?
In order to call wait() on any object, the current thread has to own its monitor. You're calling barrier.wait() without any synchronized(barrier).
However, you may have meant to use the await() method (on CyclicBarrier) instead of wait(). It's hard to say, as it's not clear what you're trying to achieve.
yeah, you need to gain the monittor of barrier like so:
synchhronized(barrier){
try {
barrier.wait();//java.lang.IllegalMonitorStateException not thrown on this line
} catch (InterruptedException e) {
e.printStackTrace();
}
}
Maybe you did want to use await() instead that wait()?
wait is used to block a thread over a specific object and it is a feature of every object, but in your case you are calling it without taking the monitor of it. You should call wait from inside the same obect or use a synchronized block over barrier itself.
You need to acquire lock before using the barrier object.
Regards,
Dheeraj Joshi
The cyclicBarrier is not intended to be used as you do here : participating threads are expected to call the blocking "await()" method.
As a side note, a CyclicBarrier with a count of 1 is totally useless : its intent is to allow a certain number of threads (the barrier count) to wait for each other before continuing.
Maybe you should consider changing your whole algorithm, especially if you're not sure about how concurrency stuff works.