Fwd: Help with debugging a POSIX timing test.

Joel Sherrill joel.sherrill at OARcorp.com
Mon Nov 25 19:10:49 UTC 2013 

On 11/25/2013 10:58 AM, Chirayu Desai wrote:
> 
> Sorry, I sent the last message to only Joel.

I MIGHT have eventually gotten to it. But am swamped.

> ---------- Forwarded message ----------
> From: *Chirayu Desai* <chirayudesai1 at gmail.com
> <mailto:chirayudesai1 at gmail.com>>
> Date: 25 November 2013 15:30
> Subject: Re: Help with debugging a POSIX timing test.
> To: Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at oarcorp.com>>
> 
> 
> 
> 
> 
> On 25 November 2013 00:35, Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at oarcorp.com>> wrote:
> 
>     Now that I can see and run the code, a few things
>     jump out.
> 
>     + POSIX priorities -- lower numerically ==> more important
>     + You did &Thread_Id to calls after created. The & isn't
>     supposed to be there. 
> 
>     + &policy should be the second argument to
>     pthread_getschedparam.
> 
> This explains the ESRCH I was getting. 

Yep. And one of the compiler warnings as well. :)

>     + Pay attention to compiler warnings. :)
> 
> Sorry for not doing so. 

No problem. This is a good example of how properly addressing
the warning would have fixed the issue with no time in the
debugger. Good programming practices try to keep you out of
a debugger. :)

>     + Benchmark time is initialized IMMEDIATELY BEFORE the
>     single operation under test. We try to avoid including
>     anything.
> 
> Got it. 
> 
> 
>     I have attached a new version of init.c with comments
>     hacked in and changes.
> 
> Thanks. 
> 
> 
>     The big thing I tried to put in a comment block is that
>     the way this test is structured, it includes the hidden
>     start up time for the first time test_thread(0 runs.
>     I tried to write up notes on how to modify the test
>     to avoid that.
> 
> I was unable to understand all of it.
> From what I understood, POSIX_Init is called first, which
> cals benchmark_pthread_setschedparam.
> That creates a new thread, gets the priority and policy, and then
> setschedparam is called
> with the new (lowered) priority, which is what we want to test.

pthread_create() creates and starts the thread. If it is
more important than POSIX_Init(), it will immediately be
switched to and run. But it isn't so it won't run until
POSIX_Init() lowers its priority.


>     For convenience, I would add a helper routine like
>     this:
> 
>     void set_thread_priority( id, new_priority )
> 
>     and call it. It will greatly simplify the code.
> 
> Noted, I will do that after I get a better understanding of the code. 

Since you will be changing priority multiple times to switch
back and forth, this will really help tighten the code.


>     I hope I didn't fall into the inverse
>     priority range trap in those instructions....
> 
>     WARNING: POSIX priorities run INVERSE from the internal
>     priorities but in gdb if you print:
> 
>     p _Per_CPU_Information.per_cpu.executing->current_priority
> 
>     You will see the internal priority (NOT POSIX priority)
>     of the currently running thread. 1 is most important
>     and 255 is the IDLE task.
> 
> I'm confused.
> Per http://www.rtems.org/onlinedocs/doxygen/cpukit/html/group__POSIX__PRIORITY.html#gada0c9a015d42fd545af7454f1ca0d098,
> "RTEMS Core has priorities run in the opposite sense of the POSIX API."
> So, for this task, lowering the POSIX priority is what we want, it is
> the output I'm getting which confuses me
> 
> Original priority: 2
> Lowered priority: 4

I am going to do this as a mix of internal and
POSIX priorities

Internal 255 is the lowest priority and illegal in POSIX.
Internal 253 = POSIX_Init() at start (POSIX 2)
   see cpukit/posix/src/pthread.c for the default attributes

Where you say lowered, it is actually becoming more important
and moving to a numeric value with numbers above and below.
At 2, there is little room below it. It is the next to lowest
POSIX priority value.

test_thread() is created at priority 2 also because the
attributes are NULL.

What you print as "Lowered priority" is actually the priority
of test_thread() if I am reading things correctly.

Hint: Make your set priority helper take (const char *, id, priority)
and you can print the thread name in debug messages. :)

When I break at test_thread(), the priority is POSIX=4, Internal=251



>     So the numbers you pick are important to switch back and
>     forth between the tasks.
> 
>     I think the test is pretty close in spite of all that I
>     wrong. I stepped through the code attached and it is
>     doing the right thing EXCEPT including the thread hidden
>     start time. :)
> 
>     Benchmark programs are hard to get right but fun to write.
> 
> Indeed 

:)

Hope this helps.

Stepping in gdb and printing the priority of the current thread
helps. It will be the internal priority though.

b POSIX_Init
b test_thread

and use

p _Per_CPU_Information.per_cpu.executing->current_priority


> 
>     --joel
> 
>     On 11/24/2013 11:50 AM, Joel Sherrill wrote:
>     > Sorry to be lazy/stupid but how to I download just
>     > the diff to see what's going on? I am not that
>     > github literate.
>     >
>     > --joel
>     >
>     > On 11/24/2013 11:28 AM, Chirayu Desai wrote:
>     >> Hello everyone.
>     >>
>     >> I am Chirayu Desai, a high school student, currently participating in
>     >> Google Code-In 2013
>     >>
>     >> I have currently working on the task [0], but I'm having some trouble
>     >> trying to get my code[1] to work.
>     >>
>     >> The task is to create a POSIX timing test psxtmthread05.
>     >> The test case is: pthread_setschedparam() - lower own priority.
>     >> I managed to write up something [2], but it doesn't work.
>     >> The GDB output is:
>     >>
>     >> (gdb) r
>     >> Starting program:
>     >>
>     /home/cdesai/rtems/b-sis/sparc-rtems4.11/c/sis/testsuites/psxtmtests/psxtmthread05/psxtmthread05.exe
>     >>
>     >>
>     >> *** POSIX TIME TEST PSXTMTHREAD05 ***
>     >> getschedparam: 3
>     >> Original priority: 5
>     >> Lowered priority: 4
>     >> setschedparam: 3
>     >> pthread_setschedparam - lower own priority 2226
>     >> *** END OF POSIX TIME TEST PSXTMTHREAD05 ***
>     >> [Inferior 1 (process 42000) exited normally]
>     >>
>     >> [0]:
>     >>
>     http://www.google-melange.com/gci/task/view/google/gci2013/6383096106582016
>     >> [1]: https://github.com/chirayudesai/rtems/tree/psxtmthread05
>     >> [2]:
>     https://github.com/chirayudesai/rtems/commit/890cebf084ca2a3815e3049a766276ddcdb0188a
>     >>
>     >> P.S. This is my first post to this list, so excuse me for any
>     mistakes.
>     >>
>     >> Regards,
>     >> Chirayu Desai
>     >
>     >
>     >
> 
> 
> 
>     --
>     Joel Sherrill, Ph.D.             Director of Research & Development
>     joel.sherrill at OARcorp.com        On-Line Applications Research
>     Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>     Support Available                (256) 722-9985
> 
> 
> 



-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

More information about the devel mailing list