Thread question

[Joel Sherrill <joel@OARcorp.com>]

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