Does POSIX standard say EXPLICIT or IMPLICIT SCHED

[Joel Sherrill]

Ralf Corsepius wrote:
> 
> Am Mit, 2002-12-04 um 18.18 schrieb Joel Sherrill:
> > Till Straumann wrote:
> > >
> > > I guess I was naive when I first wrote the benchmark code - I figured
> > > POSIX was a standard
> > > and hence the defaults would be standardized.
> >
> > HAHAHAHA!!!  :)  The reason for this perception is that in general
> > things are portable.
> 
> <*fg*> pthread_attr_setschedpolicy </*fg*>
> 
> SUSV3 says "SCHED_OTHER, SCHED_RR and SCHED_FIFO shall ..."
> 
> SCHED_OTHER is the default on most systems, but ..
> * what is SCHED_OTHER?

The user doesn't know.  As you know it is unspecified and implementation
dependent.  I assume it should be documented by the OS vendor.  For
RTEMS, these variations impact the timeslicing of the individual
task/thread.

  SCHED_OTHER - reset thread timeslice on each switch
  SCHED_RR    - exhaust timeslice before getting a new allotment
  SCHED_FIFO  - no timeslicing.

SCHED_OTHER in RTEMS is somewhat meaningful since it makes POSIX thread
timeslicing behave like timesliced Classic tasks.  But it is certainly
not guaranteed to be like any other OS.

> * Some "POSIX-compliant" OSes do not provide SCHED_RR or SCHED_FIFO

I recall that they were new in 1003.1b -- not in 1003.1.  So OSes that
have never really been updated to POSIX circa 1994 don't have them. 

> * Some schedulers require special permission (eg. root) or system
> settings on some systems.

Linux for one is in this category.  I have written code to ignore 
the EPERM/EINVAL errors from Linux if you try to do a
pthread_setschedparam
for SCHED_RR.  It is the same for SCHED_FIFO.

> ...
> 
> Ralf

-- 
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