> Date: Thu, 17 Jan 2008 10:25:27 -0800 (PST)
> From: Glenn Skinner <glenn.skinner at sun.com>
> Subject: Re: 2008/039 [POSIX scheduling interfaces]
> To: psarc-ext at sac.sfbay.sun.com, Roger.Faulkner at sun.com
> Cc: bart.smaalders at sun.com, john.zolnowsky at sun.com, darrin.johnson at
> sun.com
>
...
> So far, so good...
>
> To make the sched_*() and pthread_*() scheduling interfaces deal
> with proper priority ranges, as defined by the priocntl(2)
> interface, not the inverted nice value ranges as is done now for
> SCHED_OTHER.
>
> ... but this change introduces an incompatibility, does it not?
Yes, but it rectifies a standards violation.
The standards interfaces require priorities, low to high,
to reflect real scheduling priorities, low to high.
See the bugids:
6379296 UNIX03: *vsrte* pthread_mutex_timedlock 8, 9 fail because thread did
not
inherit priority
6466689 UNIX03: *vsrt* sched_get_priority_max 1 fails, pthread_setschedparam
set
prio above max
The old behavior of returning nice values (inverted at that)
was just a badly mistaken bug.
> To change the definition of the subcommand
> PC_GETPRIRANGE
> of the priocntl(2) interface and to invent a new
> PC_DOPRIO
> subcommand for the priocntl(2) interface, requiring
> changes to the kernel scheduling class interface:
> CL_GETCLPRI()
> Each scheduling class must change its interface definition.
> CL_DOPRIO()
> Each scheduling class must inplement this new interface.
>
> And finally to change the pthread default 'inheritsched' attribute
> for pthread_create(3C) from:
> PTHREAD_EXPLICIT_SCHED
> to:
> PTHREAD_INHERIT_SCHED
>
> And don't these as well (excepting adding PD_DOPRIO)?
>
> What stability level do the symbols you plan to remove have? What
> stability levels do you propose for their replacements? What
> will/might break should this project integrate as proposed? (What's
> your best assessment of who or what might depend on the things the
> project makes incompatible changes to?)
Well, my understanding of the scheduler class interfaces in the
kernel is that it is all uncommitted, unstable, whatever.
Not even as high as 'evolving'.
The priocntl() interfaces are a bit higher, but the PC_GETPRIRANGE
subcommand in particular is consolidation private:
>From <sys/priocntl.h>:
#define PC_GETPRIRANGE 5 /* Get global priority range for a class */
/* posix.4 scheduling, not for general use */
and my addition to this file should also be consolidation private:
#define PC_DOPRIO 11 /* Set or get priority, not for general use */
I'm not deleting any visible symbols.
The THREAD_MIN_PRIORITY and THREAD_MAX_PRIORITY were never
visible as themselves. Only thr_setprio() and thr_getprio()
ever documented their ranges.
What will break? It's hard to say.
Something that actually believed the old stuff worked, I guess.
(It never did.)
Certainly, third-party scheduling classes will break.
But I couldn't find any using Google.
The most important thing to support is actual real-time threads
and processes, and the SCHED_RR and SCHED_FIFO interfaces remain
the same as before. (The old stuff actually worked for real-time.)
Roger
