<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 November 2013 02:45, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi<br>
<br>
This should be closer than the version you posted<br>
on Melange. I added printf's to help show where<br>
the context switches from one thread to another<br>
were occurring. See if you can follow what is<br>
going on.<br></blockquote><div>Yes, I'm able to understand the context switches now. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Remember the test description is:<br>
<br>
pthread_setschedparam - lower own priority, preempt</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
which means that the benchmark operation starts<br>
in one thread which lowers its priority allowing<br>
another thread to run. When that thread runs it<br>
will stop the timer and report.<br></blockquote><div>I missed that, my bad. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Feel free to ask questions about what the code<br>
is doing.<br></blockquote><div>The printfs made it really clear this time, thanks. </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
On 11/25/2013 9:49 PM, Chirayu Desai wrote:<br>
><br>
><br>
><br>
> On 26 November 2013 00:40, Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a><br>
</div><div class="im">> <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>> wrote:<br>
><br>
> On 11/25/2013 10:58 AM, Chirayu Desai wrote:<br>
> ><br>
> > Sorry, I sent the last message to only Joel.<br>
><br>
> I MIGHT have eventually gotten to it. But am swamped.<br>
><br>
> > ---------- Forwarded message ----------<br>
> > From: *Chirayu Desai* <<a href="mailto:chirayudesai1@gmail.com">chirayudesai1@gmail.com</a><br>
> <mailto:<a href="mailto:chirayudesai1@gmail.com">chirayudesai1@gmail.com</a>><br>
</div><div class="im">> > <mailto:<a href="mailto:chirayudesai1@gmail.com">chirayudesai1@gmail.com</a> <mailto:<a href="mailto:chirayudesai1@gmail.com">chirayudesai1@gmail.com</a>>>><br>
> > Date: 25 November 2013 15:30<br>
> > Subject: Re: Help with debugging a POSIX timing test.<br>
> > To: Joel Sherrill <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a><br>
> <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
</div><div class="im">> > <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a> <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>>><br>
> ><br>
> ><br>
> ><br>
> ><br>
> ><br>
> > On 25 November 2013 00:35, Joel Sherrill<br>
> <<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a> <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>><br>
</div>> > <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a><br>
<div class=""><div class="h5">> <mailto:<a href="mailto:joel.sherrill@oarcorp.com">joel.sherrill@oarcorp.com</a>>>> wrote:<br>
> ><br>
> > Now that I can see and run the code, a few things<br>
> > jump out.<br>
> ><br>
> > + POSIX priorities -- lower numerically ==> more important<br>
> > + You did &Thread_Id to calls after created. The & isn't<br>
> > supposed to be there.<br>
> ><br>
> > + &policy should be the second argument to<br>
> > pthread_getschedparam.<br>
> ><br>
> > This explains the ESRCH I was getting.<br>
><br>
> Yep. And one of the compiler warnings as well. :)<br>
><br>
> > + Pay attention to compiler warnings. :)<br>
> ><br>
> > Sorry for not doing so.<br>
><br>
> No problem. This is a good example of how properly addressing<br>
> the warning would have fixed the issue with no time in the<br>
> debugger. Good programming practices try to keep you out of<br>
> a debugger. :)<br>
><br>
> > + Benchmark time is initialized IMMEDIATELY BEFORE the<br>
> > single operation under test. We try to avoid including<br>
> > anything.<br>
> ><br>
> > Got it.<br>
> ><br>
> ><br>
> > I have attached a new version of init.c with comments<br>
> > hacked in and changes.<br>
> ><br>
> > Thanks.<br>
> ><br>
> ><br>
> > The big thing I tried to put in a comment block is that<br>
> > the way this test is structured, it includes the hidden<br>
> > start up time for the first time test_thread(0 runs.<br>
> > I tried to write up notes on how to modify the test<br>
> > to avoid that.<br>
> ><br>
> > I was unable to understand all of it.<br>
> > From what I understood, POSIX_Init is called first, which<br>
> > cals benchmark_pthread_setschedparam.<br>
> > That creates a new thread, gets the priority and policy, and then<br>
> > setschedparam is called<br>
> > with the new (lowered) priority, which is what we want to test.<br>
><br>
> pthread_create() creates and starts the thread. If it is<br>
> more important than POSIX_Init(), it will immediately be<br>
> switched to and run. But it isn't so it won't run until<br>
> POSIX_Init() lowers its priority.<br>
><br>
><br>
> That makes it much more clear.<br>
><br>
><br>
><br>
> > For convenience, I would add a helper routine like<br>
> > this:<br>
> ><br>
> > void set_thread_priority( id, new_priority )<br>
> ><br>
> > and call it. It will greatly simplify the code.<br>
> ><br>
> > Noted, I will do that after I get a better understanding of the code.<br>
><br>
> Since you will be changing priority multiple times to switch<br>
> back and forth, this will really help tighten the code.<br>
><br>
> Done [0] :)<br>
><br>
><br>
><br>
> > I hope I didn't fall into the inverse<br>
> > priority range trap in those instructions....<br>
> ><br>
> > WARNING: POSIX priorities run INVERSE from the internal<br>
> > priorities but in gdb if you print:<br>
> ><br>
> > p _Per_CPU_Information.per_cpu.executing->current_priority<br>
> ><br>
> > You will see the internal priority (NOT POSIX priority)<br>
> > of the currently running thread. 1 is most important<br>
> > and 255 is the IDLE task.<br>
> ><br>
> > I'm confused.<br>
> > Per<br>
> <a href="http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__POSIX__PRIORITY.html#gada0c9a015d42fd545af7454f1ca0d098" target="_blank">http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__POSIX__PRIORITY.html#gada0c9a015d42fd545af7454f1ca0d098</a>,<br>
> > "RTEMS Core has priorities run in the opposite sense of the POSIX<br>
> API."<br>
> > So, for this task, lowering the POSIX priority is what we want, it is<br>
> > the output I'm getting which confuses me<br>
> ><br>
> > Original priority: 2<br>
> > Lowered priority: 4<br>
><br>
> I am going to do this as a mix of internal and<br>
> POSIX priorities<br>
><br>
> Internal 255 is the lowest priority and illegal in POSIX.<br>
> Internal 253 = POSIX_Init() at start (POSIX 2)<br>
> see cpukit/posix/src/pthread.c for the default attributes<br>
><br>
> Where you say lowered, it is actually becoming more important<br>
> and moving to a numeric value with numbers above and below.<br>
> At 2, there is little room below it. It is the next to lowest<br>
> POSIX priority value.<br>
><br>
> test_thread() is created at priority 2 also because the<br>
> attributes are NULL.<br>
><br>
> What you print as "Lowered priority" is actually the priority<br>
> of test_thread() if I am reading things correctly.<br>
><br>
> Hint: Make your set priority helper take (const char *, id, priority)<br>
> and you can print the thread name in debug messages. :)<br>
><br>
> When I break at test_thread(), the priority is POSIX=4, Internal=251<br>
><br>
> I'm getting the hang of this now.<br>
><br>
><br>
> > So the numbers you pick are important to switch back and<br>
> > forth between the tasks.<br>
> ><br>
> > I think the test is pretty close in spite of all that I<br>
> > wrong. I stepped through the code attached and it is<br>
> > doing the right thing EXCEPT including the thread hidden<br>
> > start time. :)<br>
> ><br>
> > Benchmark programs are hard to get right but fun to write.<br>
> ><br>
> > Indeed<br>
><br>
> :)<br>
><br>
> Hope this helps.<br>
><br>
> Stepping in gdb and printing the priority of the current thread<br>
> helps. It will be the internal priority though.<br>
><br>
> b POSIX_Init<br>
> b test_thread<br>
><br>
> and use<br>
><br>
> p _Per_CPU_Information.per_cpu.executing->current_priority<br>
><br>
> Using breakpoints did help, thanks.<br>
><br>
> I have attached a new patch, and cross-posted it to melange as well.<br>
><br>
><br>
> ><br>
> > --joel<br>
> ><br>
> > On 11/24/2013 11:50 AM, Joel Sherrill wrote:<br>
> > > Sorry to be lazy/stupid but how to I download just<br>
> > > the diff to see what's going on? I am not that<br>
> > > github literate.<br>
> > ><br>
> > > --joel<br>
> > ><br>
> > > On 11/24/2013 11:28 AM, Chirayu Desai wrote:<br>
> > >> Hello everyone.<br>
> > >><br>
> > >> I am Chirayu Desai, a high school student, currently<br>
> participating in<br>
> > >> Google Code-In 2013<br>
> > >><br>
> > >> I have currently working on the task [0], but I'm having<br>
> some trouble<br>
> > >> trying to get my code[1] to work.<br>
> > >><br>
> > >> The task is to create a POSIX timing test psxtmthread05.<br>
> > >> The test case is: pthread_setschedparam() - lower own priority.<br>
> > >> I managed to write up something [2], but it doesn't work.<br>
> > >> The GDB output is:<br>
> > >><br>
> > >> (gdb) r<br>
> > >> Starting program:<br>
> > >><br>
> ><br>
> /home/cdesai/rtems/b-sis/sparc-rtems4.11/c/sis/testsuites/psxtmtests/psxtmthread05/psxtmthread05.exe<br>
> > >><br>
> > >><br>
> > >> *** POSIX TIME TEST PSXTMTHREAD05 ***<br>
> > >> getschedparam: 3<br>
> > >> Original priority: 5<br>
> > >> Lowered priority: 4<br>
> > >> setschedparam: 3<br>
> > >> pthread_setschedparam - lower own priority 2226<br>
> > >> *** END OF POSIX TIME TEST PSXTMTHREAD05 ***<br>
> > >> [Inferior 1 (process 42000) exited normally]<br>
> > >><br>
> > >> [0]:<br>
> > >><br>
> ><br>
> <a href="http://www.google-melange.com/gci/task/view/google/gci2013/6383096106582016" target="_blank">http://www.google-melange.com/gci/task/view/google/gci2013/6383096106582016</a><br>
> > >> [1]: <a href="https://github.com/chirayudesai/rtems/tree/psxtmthread05" target="_blank">https://github.com/chirayudesai/rtems/tree/psxtmthread05</a><br>
> > >> [2]:<br>
> ><br>
> <a href="https://github.com/chirayudesai/rtems/commit/890cebf084ca2a3815e3049a766276ddcdb0188a" target="_blank">https://github.com/chirayudesai/rtems/commit/890cebf084ca2a3815e3049a766276ddcdb0188a</a><br>
> > >><br>
> > >> P.S. This is my first post to this list, so excuse me for any<br>
> > mistakes.<br>
> > >><br>
> > >> Regards,<br>
> > >> Chirayu Desai<br>
> > ><br>
> > ><br>
> > ><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Joel Sherrill, Ph.D. Director of Research &<br>
> Development<br>
> > joel.sherrill@OARcorp.com On-Line Applications Research<br>
> > Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
> > Support Available (256) 722-9985<br>
> ><br>
> ><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Joel Sherrill, Ph.D. Director of Research & Development<br>
> joel.sherrill@OARcorp.com On-Line Applications Research<br>
> Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
> Support Available (256) 722-9985<br>
><br>
><br>
<br>
<br>
<br>
--<br>
Joel Sherrill, Ph.D. Director of Research & Development<br>
joel.sherrill@OARcorp.com On-Line Applications Research<br>
Ask me about RTEMS: a free RTOS Huntsville AL 35805<br>
Support Available (256) 722-9985<br>
</div></div></blockquote></div><br></div></div>