No. It's depending on scheduling and it's undertimistic.
Previously thread still running. In fact they're running both. They're
thread
One or 256 CPU don't matter.
Well, it matters if you think that "running" means "actually running on
a CPU", i.e., having its instructions executed right now, rather than
"ready to be run if/when a scheduler assigns it to a CPU". It's true
that multithreading / multitasking can make it appear that multiple
threads are running at the same time on a single CPU, but when writing
multithreaded applications it's probably a good idea to realize that
this *is* an illusion .... (I might need to add some caveats about
hyperthreading technology, but I think the basic point I'm making --
which is that the number of threads that are actually running (in my
sense of the word) is limited by the hardware -- works there too.)
You are right, however -- and this is a good point to make -- that
which thread is running (in the sense of actually running) depends
on scheduling decisions, and the Java spec doesn't spell out too
many requirements about how those should be made, presumably to
give implementers some flexibility. And in fact implementations
*do* differ in how they schedule threads -- e.g., whether they use
time-slicing or just run each thread until it ends or blocks.
The point I wanted to make, however, is that the standard advice for
writing multithreaded applications in Java is that you should *NOT*
depend on scheduling decisions to make your program work, but instead
should code so that your program will work on any standard-conforming
implementation. If you need for the thread that was just started to
make some progress before other threads do something else, you should
use explicit synchronization (waits, synchronized methods, whatever)
to make sure that happens.
