Project Home
Project Home
Documents
Documents
Wiki
Wiki
Discussion Forums
Discussions
Project Information
Project Info
Forum Topic - Query on round robin: (11 Items)
   
Query on round robin  
Hello,
   Attached is a test program where 2 threads are created. Both the threads run at the same priority. But I never see 
prints coming out of the second thread. Only the first thread keeps printing. Why is that so? Are both threads not 
supposed to print based on the fact that are running at a priority of 10 with RR scheduling policy.
Attachment: Text thread-test.c 854 bytes
Update: Query on round robin  
I ran the program in QNX 6.3.2 environment.
Re: Query on round robin  
Rajorshi Dam wrote:
> Hello,
>    Attached is a test program where 2 threads are created. Both the threads run at the same priority. But I never see 
prints coming out of the second thread. Only the first thread keeps printing. Why is that so? Are both threads not 
supposed to print based on the fact that are running at a priority of 10 with RR scheduling policy.
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post55904


Looks like a bug in the thread scheduler to me.

I can reproduce your problem in 6.4.1 but not in 6.5.0.  There were a number of changes to the thread scheduler as to
when we put threads on the head of their ready queue vs the end. No doubt one of those changes solved the problem.


Re: Query on round robin  
Hello Attilla,
   So this bug exists in all versions of QNX till 6.4 and there are no bug fixes for this issue. Am I right?
Re: Query on round robin  
By adding fflush( stdout ), you will get what you expect.  (I ran on 6.4.1)   For example,

     while(1)
     {
       printf("Printing from thread 2\n");
       fflush( stdout );
     }

Even though now you see output from both threads, your program is a very un-realistic example. That is because the 
threads require very little cpu themselves.
w
If you run the system profiler on this, you will see that your thread routines occupy the cpu maybe one-fourth of cpu 
time.  That is because when they call printf(), the thread reliinquishes control (mostly) to devc-pty... which is about 
all they do!

The attached program may be a better example of round-robin thread scheduling.  It clearly shows the "fairness" of round
-robin scheduling.  (Note the addition of pthread_barrier_wait(&barrier) which was missing in your thread routines.)

Attachment: Text 1.c 1.05 KB
Re: Query on round robin  
Hello Dennis,
   I ran the 1.c program that you attached and it showed the fairness of the RR scheduler. Thanks for the program.
   But I am still not able to see prints coming out of both the threads in my original problem code, inspite of using 
fflush. I am attaching the newly modified code. I ran this on QNX 6.4.1 but only the thread1 keeps getting printed in 
that case. If I use sleep instead of fflush, the program works fine and both the threads print data. That is the reason 
why I started suspecting the RR scheduler. Also when I run the same program on Ubuntu Linux 9.10, both the threads print
 out data. Only when I am using QNX (I used 6.4.1), the thread 2 never prints anything. Can you please explain this?
Attachment: Text thread_test.c 1.05 KB
Re: Query on round robin  
Rajorshi Dam wrote:
> Hello Attilla,
>    So this bug exists in all versions of QNX till 6.4 and there are no bug fixes for this issue. Am I right?

I only checked 6.4.1 and 6.5.0. It's possible the behavoir was inserted in 6.4.1.

However I note that putting a small busy-loop before your printf() statements causes the problem to go away.
So in general round-robin is not broken in 6.4.1. But there is something peculiar triggered when calling printf() in a 
very tight loop in 6.4.1.

-ad
Re: Query on round robin  
Using your program, I see output from both threads on an N270 Atom netbook running 6.4.1 SMP kernel.  Output from '1' 
may show for about a second, but eventually output from '2' will show for awhile.  Sometimes they alternate frequently.

Are you runing on x86?  Using procnto-smp-instr?
Re: Query on round robin  
I ran the program in QNX 6.4.1 running within a virtual machine (using MS Virtual PC 2007 for that). I am running in 
that on an Intel Core 2 Duo platform. Running "objdump -x" on the executable shows me architecture as i386. Yes, it is 
running on x86 with procnto-smp-instr. I am attaching the executable also this time. I compiled with "-g" option.

Attachment: Text thread_test 9.72 KB
Re: Query on round robin  
FYI, your binary works correctly (same as mine) on a physical cpu.
Re: Query on round robin  
I haven't used Virtual PC before, but we are well aware that VMWare
plays very fast and loose with times and timers.  We never use it when
what we are testing is at all time sensitive.  I suspect Virtual PC is
the same.

On Wed, 2010-06-02 at 22:59 -0400, Rajorshi Dam wrote:
> I ran the program in QNX 6.4.1 running within a virtual machine (using MS Virtual PC 2007 for that). I am running in 
that on an Intel Core 2 Duo platform. Running "objdump -x" on the executable shows me architecture as i386. Yes, it is 
running on x86 with procnto-smp-instr. I am attaching the executable also this time. I compiled with "-g" option.
> 
> 
> 
> 
> 
> _______________________________________________
> 
> OSTech
> http://community.qnx.com/sf/go/post55972