Will Thread release the lock it holds when it enters sleep state?

As far as I know, Thread releases the lock it holds when it enters wait state. How about when sleep(), or interrupt() method is invoked on the Thread object? Will the thread release the lock immediately?
In the deprecated suspend() method, the thread may keep the lock which may result in deadblock when the thread is suspended by other threads.
Thanks.
Judy

Good question , i am also having questions on threads, i think what's happening is this. Thread acuires a monitor so it can perform something on this object when it's been issued a sleep method it goes to waiting stage so it must give up the monitor so other threads can use it ( i think) . Same goes for the wait

Hi,
I have doubts too. in my understanding:
if call the wait() method, the thread release the lock, and goto the monotor's waiting pool.
there are two thing must be require:
1)the wait() method must be called in a block of sychchronized code.
2) at that monment, the thread must have the lock.
for the sleep() method, it is different:
the thread do NOT need have the lock, when it is called, the thread go to sleeping state, after certain time or call interrupt(), the thread go to the ready state, prepare to run
Am I right?

As far as I've always known, the thread doesn't lose the lock when it goes into a sleeping state, but it does when it goes into a waiting state. Someone correct me if I'm wrong, but I'm pretty sure this is how it works. Don't ask me why.

don't know if i am reading a book right or i am reading wrong along the lines but it says that when the thread is issues sleep method it goes into a waiting stage . This i think means it looses a monitor. I might be wrong. I want to hear more on this.

Kevin is correct.
The sleep() state does not release any monitor and sleeping is not comparable to the wait() state.
Bill

Here is what i read maybe someone can interpret it better:
Waiting Stage: When in the running state a thread can call the wait method defined in the object clas to put itself into the waiting state . It must be notified by another thread in order to move to The read to run state:
Sleepign state:
A call to the static method sleep in the thread class causes teh current thread in the runnning state to tranist to the sleeping state it wakes up after a specified amount of time has elsapsed and transists to the Ready to run state.
So in my opinion sleeping state is just one of the waiting stages like wait only it doesn't need a notify method to be wakened up. So i think it releases monitor just like the wait method.

No,
A thread does not lose its monitor while sleeping.

well i need more explanation then this , how can you proove it ? Is there any material avaialable on this to read ?

Hi Val Dra,
Following is from JDK 1.3 API

Causes the currently executing thread to sleep (temporarily cease execution) for the specified number of milliseconds. The thread does not lose ownership of any monitors.

Hope that helps.

------------------
Jane Griscti
Sun Certified Java 2 Programmer
"When ideas fail, words come in very handy" -- Goethe
[This message has been edited by Jane Griscti (edited February 01, 2001).]

I see thanks.

Hi guys,
I think you have mixed up synchronization and relinquishing the C.P.U.Waiting & notifying provide a means of communication between threads that "synchronize on the same object".That is what the concept of obtaining a monitor is all about.So that at any time not more than one thread can can own the monitor.Wait() method comes in this context.So only another object that has the monitor can notify this waiting thread.
sleep() method just gives up it's C.P.U time(NOTE: It doesn't give up any locks on any object) and gets into an idle state.

Priya Kannan,
You are absolutely right. We shoudln't mix up the 2 different concepts: "synchronization and relinquishing".
Hungson Le

Thanks for all your kind reply.
So now I see that the static method sleep() of Thread won't relinquish the lock of the object if it happened to be called inside synchronized method. And sleep() is definitely different from wait() since the latter must be called inside synchronized block.
But nobody answered my other question: what happened if interrupt() is called on this thread? I assume the thread will immediately relinquish the lock it holds if this method is called inside a synchronized block. But if the thread is interrupted while it is still in waiting state, the InterruptedException won't be thrown until the thread re-obtain the lock, and entering running state at the mercy of Thread scheduler. Right?
Question about another static method of Thread, yield(): java API says: Causes the currently executing thread object to temporarily pause and allow other threads to excute. So what kinds of threads will get the chance to excute? Those threads who have higher or equal priority as the current Thread? It is said that the when a Thread gets to run is platform-dependent because some platforms may use priority-preemptive mechanism,i.e, threads of lower thread never get chance to run before all other threads with higher priority die, and some platform have time-slice mechanism, in this case lower priority and higher priority thread alternatively get chance to run. Therefore, does this mean on different platform, yield() will enable different thread to execute, including threads whose priority is lower than current ones?
Judy

interrupt() puts a sleeping/waiting thread into the ready state. that is, an interrupted thread which was waitng/sleeping earlier gets up, yawns and starts asking the cpu for time.
i'm repeating sleeping/waiting coz interrupt() can be called on a running thread too. but here, it is upto the running thread to check its state;' interrrupted and realize it has been interrupted. for all you know, it may never check!

If I am wrong, please correct it.
1)when the thread is in sleeping/waiting states
if the interrupt() method was called, there is a "InterruptException", the thread is back to ready state,you will deal it with catch{....}
2) when the thread is not in the sleeping/waiting states
there is NO "InterruptException" generated ( you need another method which is interrupted() to check the thread is interrupt ot not)
3) I think either type operating system will be High Priority First.otherwise, in the time-slice operating system, the gc() will always working. ( I will check some operating system book)