Timeslicing question

Joel Sherrill joel.sherrill at OARcorp.com
Fri Oct 3 18:21:54 UTC 2003

Kenneth Peters wrote:

> My tasks are truly preemptible and timeslicing. I had already used a
> modified CPU_usage_Dump() function from the RTEMS-4.5.0 libmisc directory
> to print out the is_preemptible and budget_algorithm parameters (among
> others). Also, I used the rtems_task_switch_extension to log 
> information at
> every task switch so I could see which tasks were executing and how their
> cpu_time_budgets were behaving.
> What I have done as a quick fix is to take a copy of the Classic API
> rtems_task_mode() function and modify it to
> rtems_status_code my_rtems_task_mode(
>   rtems_mode mode_set,
>   rtems_mode mask,
>   rtems_mode *previous_mode_set,
>   boolean use_timeslice_exhaustion,
>   boolean *previous_use_timeslice_exhaustion
> );
> and adjust the code appropriately so that a task can set itself to, in
> effect, use the SCHED_RR methodology. The basic code is
> if ( mask & RTEMS_TIMESLICE_MASK ) {
>   if ( _Modes_is_timeslice(mode_set) ) {
>     if (use_timeslice_exhaustion) {
>       executing->budget_algorithm
>     } else {
>       executing->budget_algorithm
>     }
>   } else {
>     executing->budget_algorithm
>   }
> }
> This does make my tasks act as I desired. (Actually I also set
> executing->Start.budget_algorithm since my tasks are sometimes restarted
> and I don't want that to risk getting a task stuck again.)
> Now I have to judge whether I should use this hack, or convert to POSIX
> task startup (possibly non-trivial due to things elsewhere in the code 
> like
> looking tasks up by name), or change the way my tasks work so that 
> they can
> do their jobs under the standard Classic API timeslicing method. But 
> that's
> my job.

I am open to adding another Classic API mode bit (or bits) which can be
helped to make this scheduling mode available. 

I want the Classic API to promote out all core features when possible.  The
Classic API Semaphore manager was enhanced to get access to priority
inversion and ceiling -- which weren't even in the real-time lexicon 
when those
were defined in the late 1980's.

So feel free to file a PR with a patch to add this -- please also update 
the documentation
in the patch.  Doing that HAS to be easier than switching your 
application to the
Classic API.


> Thanks for the help,
> Ken
> At 05:34 PM 10/2/2003 -0700, Kamen Penev wrote:
> >Kenneth Peters wrote:
> >
> >>Ugh. Thanks for the quick reply. This is ugly, though, if I have to go
> >>through and retrofit my task functions to the POSIX API.
> >
> >
> >It is not that much work really. Follow the example that I gave at 
> the end
> >of the second thread. You don't have to change all your tasks to POSIX.
> >Only the ones that need SCHED_RR. And you can still use classic
> >semaphores, message queues etc. inside them.
> >
> >>Joel indicated maybe the pthread_setschedparam() function could be 
> called
> >>on a Classic API task to tweak the budget_algorithm parameter. If that
> >>value is really the only thing I need to change, that would be a better
> >>way for me. Has anyone tried that?
> >
> >It didn't work for me back then, as reported in:
> >http://www.rtems.com/ml/rtems-users/2003/may/msg00158.html
> >
> >The bug may have been fixed, I don't know. Try pthread_setschedparam and
> >see what happens.
> >
> >Kamen
> >
> >
> >

More information about the users mailing list