Thread question
Kenneth Peters
Kenneth.J.Peters at jpl.nasa.gov
Mon Dec 13 17:27:01 UTC 2004
At 11:10 AM 12/13/2004 -0600, Joel Sherrill <joel at OARcorp.com> wrote:
>Kenneth Peters wrote:
>>At 10:23 AM 12/13/2004 -0600, Joel Sherrill <joel at OARcorp.com> wrote:
>>
>>>Steve Holle wrote:
>>>
>>>>At 05:05 PM 12/10/2004, Angelo Fraietta wrote:
>>>>
>>>>>Steve Holle wrote:
>>>>>
>>>>>>If I disable task 1A, 1B keeps running even with the streaming audio
>>>>>>running.
>>>>>>
>>>>>>I assumes that since 1A and 1B where set up to timeslice that
>>>>>>whatever time was left 1A and 1B would get serviced. That is
>>>>>>obviously a false assumption.
>>>>>
>>>>>
>>>>>
>>>>>I am pretty sure that if a higher priority thread takes control at any
>>>>>stage, the thread that was switched out will get switched back in;
>>>>>however, it's timeslices will start again at zero. It is possible in
>>>>>that case for one thread to get starved because the thread of equal
>>>>>priority keeps getting switched back with it's timeslice count set
>>>>>back to the start
>>>>
>>>>
>>>>I'm not sure I understand this. Why should it's timeslice restart?
>>>>That seems counter-intuitive. That would explain the symptoms we are
>>>>seeing but I'm not sure I understand the purpose and how to use
>>>>timeslicing if this is the case.
>>>
>>>
>>>THe way timeslicing is defined in the Classic API, it is just a limit on
>>>how long a thread can run without giving up the processor. If it ever
>>>gives up the CPU, it will have its timeslice reset when it runs again.
>>>
>>>POSIX has a slightly different definition of timeslice quantum
>>>handling. It is not reset until it is actually exhausted.
>>>
>>>A quick hack to try the POSIX version is to change the taskcreate.c
>>>call to _Thread_initialize to use EXHAUST_TIMESLICE not RESET_TIMESLICE.
>>>There has been a wishlist for a while to be able to specify which
>>>algorithm to use. Maybe you have finally got a case where it matters. :)
>>>
>>>--joel
>>
>>FYI, I've been using a hacked version of rtems_task_mode() to set these
>>parameters after creating classic tasks (but before starting them
>>executing). It has worked fine for me. See diffs against 4.5.0 taskmode.c
>>below.
>
>Does this address the situation he is describing?
I think so. We had the same problem, where if task A got switched out by a
higher priority task B (or possibly even an interrupt handler), when task A
got switched back in its timeslice would be restarted. If this kept
happening other tasks at the same priority as task A would never get a
chance to run.
Changing all the tasks to different priorities would avoid this problem,
and would be theoretically better in most cases, but sometimes that's not
convenient.
>>I did it this way because I did not want to hack the OS itself (for
>>administrative reasons we need to use an "oficial release" as much as
>>possible), so I made my own copy of taskmode.c to build into my own code
>>and changed the name to reveal the guilty.
>
>I don't really have a problem with this feature and think it already has
>a PR. If a patch were to show up against the CVS source with:
>
> + a modified task create
> + a modified task mode
> + updated documentation
>
>Something tells me it would get merged. :)
I'd love to submit something, but I know I won't have time to put together
something reasonable in the near future (though if no one has done it by
the time I might have a chance, I'll keep this on my list). My modified
rtems_task_mode() is a very kludgy way to do this; I think it's harmful to
just slap extra parameters into the function calls.
Ken
More information about the users
mailing list