PS: Re: Thread question

[Kenneth Peters]

At 08:45 AM 12/13/2004 -0800, 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.
>
>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.
>
>Ken Peters

PS. Shouldn't have said "before starting them executing", actually the 
tasks call this on themselves as one of the first things they do.

Ken