Well , i got an idea that scheduling algorithm and hence its decision cannot be predicted , so any application made should be independent of scheduling decision made my JVM scheduler.
We say when a certain Thread sleeps , it would go into Blocked state.
Assertion :- Suppose we have X number of threads and X>=3 and suppose there names are as follows.
and currently running thread is Sahil. Now suppose Sahil goes to sleep for some miliseconds. Say 1000 milliseconds. Moreover Ankit and stella threads are also not dead and in Runnable state. Also suppose no other Computer process is scheduled by OS while we are talking about the following.....
Is there a Possibility (not guarantee ) of Sahil to be again scheduled after 1000 milliseconds......??? I think i can guarantee that it should not be....!!! But is it so ???
Question 2:- When we say that Thread.sleep(1000), does it mean that JVM thread sleeps for 1000 milliseconds of its scheduled time by cpu or of real cpu time. Ooops let me clear. Suppose there are 10 processes running in a system and suppose we have Round Robin scheduling implemented by CPU, and time slice is 2000 ms.
Now i am concerned that is the counting of sleeping thread continues even when scheduled process by cpu is not the JVM and is the another out of 9 rest processes, or the counting continues only when JVM is running by CPU !!!
Is there a Possibility (not guarantee ) of Sahil to be again scheduled after 1000 milliseconds
You are saying it correctly: there is a possibility, but it is not likely. (i haven't seen it happening in my small thread exercises). How the Thread scheduler picks the next thread from the Runnable state is not specified.
Now i am concerned that is the counting of sleeping thread continues even when scheduled process by cpu is not the JVM
With sleep() you give other threads of your application or other applications on the same CPU a possibility to run, so counting just continues.
As Frits mentioned, it is very unlikely. Java uses (all modern JVMs) the underlying OS to implement threads, so for a OS, that is not overloaded with other tasks, to be unable to schedule either of two runnable tasks to execute, for one whole second, something is seriously wrong with it. In terms of specification, the JLS doesn't require that the OS be able to do so, so its theoretically possible.
As for sleep, the sleep time passed is clock time. The thread will sleep for the specified time before it is eligible to be scheduled (runnable) again.