Thread question

[Kenneth Peters]

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