Kenneth.J.Peters at jpl.nasa.gov
Fri Oct 3 00:10:51 UTC 2003
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).
At 04:32 PM 10/2/2003 -0700, Kamen Penev wrote:
>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:
>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).
>>Ken.Peters at jpl.nasa.gov
More information about the users