Timeslicing question

[Kenneth Peters]

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.

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?

At first glance, it does not look like that would work, since the function 
code reads as too tied to POSIX threads. However, maybe a straightforward 
modification would provide me with a Classic function that would tweak the 
budget_algorithm. It looks like that would work, but I don't know if that 
is a good idea or if it will mess up the Classic threads (or if other 
Classic thread functions will not preserve the unexpected budget_algorithm).

Ken

At 04:32 PM 10/2/2003 -0700, Kamen Penev wrote:
>Ken,
>
>What you want cannot be accomplished with the Classic API. You need to use 
>the POSIX API and specify a SCHED_RR scheduling policy. This issue was 
>discussed earlier in these threads:
>
>http://www.rtems.com/ml/rtems-users/2003/may/msg00154.html
>http://www.rtems.com/ml/rtems-users/2003/june/msg00019.html
>
>Kamen
>
>Kenneth Peters wrote:
>
>>I am using rtems-4.5.0 with the erc32 BSP (slightly modified for my 
>>board). I have a situation where there is a task of priority 99 and two 
>>tasks of priority 100. Timeslicing and preemption are enabled.
>>
>>I have not completely traced what is happening, but it seems that 
>>whichever priority 100 task gets in the priority 100 ready chain first 
>>never gets timesliced out, since _Thread_Dispatch() after the priority 99 
>>task keeps resetting the priority 100 task's cpu_time_budget, so 
>>_Thread_Reset_timeslice() never gets called to take the task off the 
>>front of the priority 100 ready chain.
>>
>>Probably I am misunderstanding something, since this seems like a simple 
>>task situation that should work. Setting different priorities does not 
>>really accomplish what I need, and manual round-robin with 
>>rtems_task_wake_after() does not seem to work right either (though I 
>>expected that would at least get the tasks taking turns, it did not seem 
>>to work. I am still looking into that).
>>
>>Any suggestions?
>>
>>Ken Peters
>>Ken.Peters at jpl.nasa.gov
>>
>>
>