Using A.join() within a thread is tantamount to making the current thread sleep until thread 'A' completes execution.
abalfazl hossein wrote:
In this program , a.join must cause another thread stops , until a dies.
However, as with sleep, join is dependent on the OS for timing, so you should not assume that join will wait exactly as long as you specify.
abalfazl hossein wrote:
1-Is it only for times that we specify a time in join() method?
2-Is it right for wait() method?
3-Is it the Os or is it the JVM choose which thread to run?
4-Who is "thread scheduler" here? is it part of OS or JVM?
M to OS Thread Mapping
The way Java threads are mapped to OS threads is up to the JVM and its use of multiple processors on a machine. Different JVMs use different strategies:
Some JVMs use green threads, running all Java threads in one native OS thread (called n-to-one mapping). Sun's HotSpot JVMA website external to this site uses native threads, which may execute in parallel on a multi-CPU machine. On Solaris, Java threads are not bound permanently to the same native threads but are remapped by the scheduler (in an n-to-m mapping).
1. The java threads are scheduled by the jvm
No they are not. Certainly not in the Sun VM. And I would doubt that for any recent VM on a desktop OS.
The OS does it.
Sure? Until I know (I'm not an expert at all) the jvm is scheduled by the OS, but the java threads are scheduled by the jvm. This way if you are running on a machine a jvm with 5 java threads and the mysql daemon, for example, OS will schedule the jvm as one process and the mysql daemon as another process. In the cpu time assigned by the OS to the jvm, it will schedule between the 5 java threads.
At best the VM will set the priority. Scheduling is by the OS.