Shouldnt the output overlap?(Threading)

[Amit Batra]

public class Threads2{
public class Run1 implements Runnable{
public void run(){
for(int i=0;i<5;i++)
System.out.println(i+",");
}
}
public static void main(String[] args)
{
new Threads2().go();
}
public void go(){
Runnable r1=new Run1();
Runnable r2=new Run1();
new Thread(r1).start();
new Thread(r2).start();
}
}

In the above I have made 2 instances of the inner class Run1 and handed them to the 2 respective threads. The o/p is a clean: 0,1,2,3,4 0,1,2,3,4. But there are two objects of Run1 class, which means there are also two sets of run methods, and each thread is executing a different run method, why arent the results overlapping??

[Gowher Naik]

public class Threads2{
public class Run1 implements Runnable{
public void run(){
for(int i=0;i<25;i++) //line 4[increase i]
System.out.println(Thread.currentThread().getName()+i);
}
}
public static void main(String[] args)
{
new Threads2().go();
}
public void go(){
Runnable r1=new Run1();
Runnable r2=new Run1();
Thread t1=new Thread(r1);
Thread t2=new Thread(r2);
t1.setName("T1: ");
t2.setName("T2: ");
t1.start();
t2.start();
}
}

i have made some changes to your code.
Run above code and see overlapped output.
If above code does not show overlapped output
increase loop number at line 4 you will get overlapped output.

[Amit Batra]

Yeah i get that if you increase the iteration count the output begins to overlap but my question is If I have two objects each object with its own copy of run and each object has 1 thread executing its run, shouldnt the output begin overlapping from the get go. Or is there only 1 thread scheduler for as many objects as one can make with diff threads? I reckon

[Scott Johnson]

 

shouldnt the output begin overlapping from the get go

Not necessarily. Just because a thread is "runnable" doesn't mean it's "running." The scheduler decides which of the runnable threads should be running.

In your case, with a small number of iterations, the scheduler is starting one thread and it finishes the small number of iterations before the scheduler preempts it.

By increasing the iteration count, the thread runs long enough to be preempted in favor of another thread.