In article
<[EMAIL PROTECTED]>, Daniel
Eischen <[EMAIL PROTECTED]> wrote:
> So far I read this as saying the sched_XXX functions operate on
> processes, whereas the pthread_{set|get}schedparam functions operate
> on threads.
Me too.
> > (4) When a running thread calls the sched_setparam() function,
> > the priority of the process specified in the function call is
> > modified to the priority specified by the param argument.
> > If the thread whose priority has been modified is a running
> > thread or is runnable, runnable thread [sic] it then becomes
> > the tail of the thread list for its new priority.
>
> This contradicts itself and is where I think it is unclear. Where
> does it state that the _threads_ priority is modified? It only
> says that the process priority is modified. When it goes on to
> say "If the thread whose priority has been modified...", it's
> assuming something that was never stated as a requirement.
Agreed. I think they meant process, not thread. The whole section
has quite a few things I suspect are typos and/or editing errors.
> > (5) When a running thread calls the pthread_setschedparam()
> > function, the thread specified in the function call is
> > modified to the specified policy and the priority specified by
> > the param argument.
>
> The above is a clearly stated requirement. If they had meant for
> the threads priority to be changed by sched_setparam(), then it
> should have been stated just as it has been above (5).
>
> > (6) If a thread whose policy or priority has been modified is
> > a running thread or is runnable, runnable thread [sic] it then
> > becomes the tail of the thread list for its new priority.
>
> Unless it holds a priority protection or inheritence mutex, in
> which case it gets added to the head of the thread list for its
> new priority. This case is often forgotten (see 13.6.1.2).
I get the feeling they rushed this part into print after making a
lot of last-minute changes to it.
> > For this policy, valid priorities shall be within the range
> > returned by the function sched_get_priority_max() and
> > sched_get_priority_min() when SCHED_FIFO is provided as the
> > parameter.
> >
> > So it seems clear that the same range of priorities shall apply to
> > individual threads as well as to processes. (SCHED_RR is similar in
> > these respects.)
>
> For SCHED_FIFO and SCHED_RR, we don't have a problem because both
> the threads library and kernel now agree that the range is 0..31.
> SCHED_OTHER is a problem because the threads library treats
> SCHED_OTHER as SCHED_RR with range 0..31. The kernel treats
> SCHED_OTHER traditionally with range -20..20.
As long as the only problem area is SCHED_OTHER, we are arguably
OK. SCHED_OTHER is almost entirely implementation-defined; it can
do practically anything. More specifically, section 13.5.2.2 (the
detailed description of pthread_[sg]etschedparam) says:
The policy parameter may have the value SCHED_OTHER, SCHED_FIFO,
or SCHED_RR. The scheduling parameters for the SCHED_OTHER policy
are implementation defined. The SCHED_FIFO and SCHED_RR policies
shall have a single scheduling parameter sched_priority.
I think it would be slightly less surprising if our implementation of
SCHED_OTHER used thread priorities in the range -20..20 just the same
as processes. But in my opinion POSIX doesn't require that.
John
--
John Polstra [EMAIL PROTECTED]
John D. Polstra & Co., Inc. Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Ch�gyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
