wait() Vs Thread.currentThread().wait()

[vikram hegde]

Hi Java pals,

Can any one help me in understanding the working calling wait() and calling Thread.currentThread().wait().

Case1>
...
synchronized(this){
this.wait();
}
...

Case2>
...
synchronized(this){
Thread.currentThread.wait();
}
...

Among the above specified code snippets, case1 invokes wait() on itself, which internally, puts the current executing thread on it into wait queue and releases the lock. In case2, we get the handle to the current executing thread by holding monitor on the same object and issue wait on that thread.

So, The question is are both the code achive the same or are they different? Please explain.

Thanks in advance,
Vikram Hegde

[Peter Chase]

Case 1 is sensible code. It waits until another thread calls notify[All]() on "this" object.

Case 2 looks silly. It could only execute if the current thread and "this" were the same object, or you already had a lock on the current thread. Otherwise, you'd get IllegalMonitorStateException. Synchronising on Thread objects is a Bad Thing, because you can't be sure what else might be synchronising on them.

By the way, if what you want to do is just pause for a while in the program, you should sleep(), not wait().

[Stan James]

When you use synchronize() wait() notify() etc you deliberately choose an object instance to use to control interaction between two or many threads. You have to make the object visible to all threads, probably by passing arguments while spawning threads.

The sync object is often one of the objects that wants to get some work done, but some little object that you use only for this purpose might be more clear.

Using one of the thread objects sounds ... odd. Look how awkward the syntax is to get the current thread. And why would the other threads want access to that object?

[Justin Chu]

Case 2 seems like an coding mistake to me. First, you have to synchronize on the object, in order to call wait() on it. Second, if multiple threads access this code, they will be synchronizing and waiting on different Thread instances, thus it is not clear what is achieved.

Generally, people use Thread.currentThread() for the purpose of calling sleep(). Notice that sleep() is a part of the services provided by the concept of a "Thread", and not available in java.lang.Object. You are actually telling a thread to sleep, in this case, it just happens that the thread is your "current" thread.

[Anton Uwe]

You are actually telling a thread to sleep, in this case, it just happens that the thread is your "current" thread.

Thread.sleep() (Thread.currentThread().sleep() is calling the static sleep() in a non-static manner) always will put the current Thread to sleep.

[Justin Chu]

You are right. Thanks for pointing out the mistake.

So, is there a way to make another thread sleeps/blocks for x ms?

[Mr. C Lamont Gilbert]

Originally posted by vikram hegde:
Hi Java pals,

Can any one help me in understanding the working calling wait() and calling Thread.currentThread().wait().

Case1>
...
synchronized(this){
this.wait();
}
...

Case2>
...
synchronized(this){
Thread.currentThread.wait();
}
...

Among the above specified code snippets, case1 invokes wait() on itself, which internally, puts the current executing thread on it into wait queue and releases the lock. In case2, we get the handle to the current executing thread by holding monitor on the same object and issue wait on that thread.

So, The question is are both the code achive the same or are they different? Please explain.

Thanks in advance,
Vikram Hegde

There is no wait() call defined on the Thread class. Case 2 will fail because you have not obtained the lock on the object Thread.currentThread() which is not the same as the object 'this'. Not to mention case 2 wont compile.

Try it out and you will see the difference immediately when it fails. But conceptually, the only difference is you are trying to wait on different objects. This has absolutely nothing to do with the fact that the one object happens to be an instance of Thread. A thread of execution and an instance of the Thread class are not the same thing, though one is used to manipulate the other.
[ March 02, 2007: Message edited by: Mr. C Lamont Gilbert ]

[Balaji Ambresh]

Well, wait is a static method and is made to make the thread that's making the wait() execute wait. So, the reference dosen't matter.
[ March 02, 2007: Message edited by: Maximus Smith ]

[Henry Wong]

Originally posted by Maximus Smith:
Well, wait is a static method and is made to make the thread that's making the wait() execute wait. So, the reference dosen't matter.

I believe you may be thinking of the sleep() method, which is a static method of the Thread class. And yes, it always causes the current thread to sleep(), so the actually thread object, that may be used as a reference doesn't matter.

The wait() method is *not* a static method. Like the sleep() method, it also causes the current thread to block. However, the object that is reference does matter as (1) you must coordinate it with the notify() method calls that will wakeup the threads, and (2) you must own the lock on the object.

Henry

[Balaji Ambresh]

u're right. thanks for the correction