In Java, how can other thread get chance to run after current thread is called on sleep() but still holds the lock?

0
votes

In Java, a thread can go to sleep so that it won't hog the process and other thread can get chance to run. This is done by calling sleep().

However, different from calling wait(), the thread, after calling sleep(), will NOT release the lock it's been holding. Since this thread is still holding the lock, how can other thread get chance to run while not being able to get the unreleased lock?

3
javamultithreadingconcurrencysleep
They can run if they don't need the locks that the sleeping thread have. If they need them they will need to wait for the other thread to wake up and unlock them – litelite
This is pretty vague, do you have a concrete example? – dimo414
Thanks for your folks' quick responses. Yes, I am talking about a thread which is holding a lock already when calling sleep(). For other thread(s), I mean those threads which attempt to acquire the same lock. If other thread can't get the lock to run while this thread is going to sleep, then what's the purpose for this thread to go sleep at first place? Of course, this doesn't matter at all for other threads that are looking to lock on different lock. – user2142271

3 Answers

5
votes

They can't; other threads that need to acquire a lock held by a sleeping thread will block until they can get it. There's no way to back off like tryacquire on explicit Locks, so the threads are stuck.

Threads shouldn't sleep while holding a lock. If a thread isn't doing something useful it doesn't need to be holding a lock.

To go dormant and release a lock use the wait method. Sleep doesn't have any means to cut its sleep time short other than interruption (which should be used for cancellation), wait lets the thread be notified.

0
votes

If you call Thread.sleep() while holding a lock or from inside a synchronized block/method, any other threads that reach that lock will wait until the first thread resumes and releases the lock.

However locks/synchronization are not global, any threads that don't reach the locks held by the sleeping thread can run without issue.

0
votes

If other thread can't get the lock to run while this thread is going to sleep, then what's the purpose for this thread to go sleep at first place?

The only person who can answer that question is the person who wrote the code that runs in the thread.

Was that you?

As Nathan Hughes said, it practically never is a good idea for a thread to sleep() while holding a mutex lock. To take that idea a little further: It almost never is a good idea for a thread to do anything that takes more than a microsecond or so while holding a mutex lock. If you find yourself writing code that waits for something while keeping a lock locked, then that's a sign that you might need to re-think the architecture.

Also, there are not many good reasons for calling sleep() at all.

In Java, a thread can go to sleep so that it won't hog the process and other thread can get chance to run.

That's not really what sleep() is for. In most cases, when a thread doesn't need the CPU, it will block in a wait() call or in some xyz.await() call (where xyz is a queue or a semaphore or a latch or some other higher-level synchronization object).

The sleep() function is a low-level, primitive that your program can call in order to meet real-time requirements. But most programs with real-time requirements can make use of higher-level facilities such as java.util.concurrent.ScheduledThreadPoolExecutor or javax.swing.Timer. If you start by writing your own sleep() calls, without first investigating the higher-level objects, then you may be re-inventing a wheel.