Does POSIX standard say EXPLICIT or IMPLICIT SCHED

[Ralf Corsepius]

Am Mit, 2002-12-04 um 19.00 schrieb 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.
Well, not necessarily. Linux falls under this category from a user's
perspective unless you are the superuser, because the only schedpolicy
to available to ordinary users is SCHED_OTHER.

=> You have to cope with SCHED_OTHER's non-deterministic run-time
behavior across systems.

> > * Some schedulers require special permission (eg. root) or system
> > settings on some systems.
> 
> Linux for one is in this category.
Solaris is another one.

>   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.
Then your application most likely will use SCHED_OTHER and the run-time
behavior will be random across different OSes.

Fortunately, most *nix-ish schedulers are similar enough for SCHED_OTHER
to provide a sufficient approximation of the desired scheduling in most
cases ;)

Ralf