SCHED_RR in Classic API?

Joel Sherrill joel.sherrill at OARcorp.com
Thu May 29 19:19:08 UTC 2003



Kamen Penev wrote:
> 
> Is it possible to specify the scheduling policy of the Posix SCHED_RR
> using the Classic API? More precisely, is it possible to create a
> classic-API task with the THREAD_CPU_BUDGET_ALGORITHM_EXHAUST_TIMESLICE
> budget algorithm or is this only feasible using Posix and Itron?

Right now, that particular timeslicing quantum behavior can only be
set through those alternate APIs.  It is possible to create the task
with the Classic API and use the pthread API calls on it to set 
that though.

So you can call pthread_XXX on a task created using the Classic API.
This would be the easiest way to get this scheduling mode.

> If the latter, can Posix and Classic tasks mix? 

Yes.

> Are there any restrictions on how they can interact? 

The only restrictions I know of are more like edge conditions.  The
behavior when a thread exits at the bottom of its loop are dependent
upon the API with which it was created.  

The worst thing I know of is that if you use the unlimited task
configuration
option in the Classic API and actually extend the number of tasks in
the system dynamically, then the number of POSIX keys is not increased
accordingly.  

I know of a large application that is in Ada95 using GNAT/RTEMS.  Ada
tasks
are implemented as POSIX threads and use the POSIX thread API heavily. 
The application uses the Timer, Rate Monotonic, and Event Managers
heavily.
They also include some C Classic API tasks.  These tasks actually call 
routines writeen in Ada when necessary.

Things work well because Classic API tasks, POSIX threads, and ITRON
tasks
are all actually SuperCore threads. 

> Can Posix threads send and
> receive Classic events and messages?

Yes.

> Thanks.
> 
> Kamen

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985



More information about the users mailing list