Date: Sun, 15 Oct 2000 00:20:11 -0400 (EDT) From: Daniel Eischen <eischen@vigrid.com> To: current@freebsd.org Subject: Re: Recent thread changes Message-ID: <Pine.SUN.3.91.1001014234955.25430B-100000@pcnet1.pcnet.com> In-Reply-To: <200010142000.e9EK0hn47439@vashon.polstra.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 14 Oct 2000 jdp@polstra.com wrote:
> In article <Pine.SUN.3.91.1001014091525.13283A-100000@pcnet1.pcnet.com>,
> Daniel Eischen <eischen@vigrid.com> wrote:
> > On Sat, 14 Oct 2000 jdp@polstra.com wrote:
> > >
> > > I thought you could get that information with sched_get_priority_min()
> > > and sched_get_priority_max(). Is that not the case?
> >
> > Not really. Those return the kernels POSIX priority range for
> > processes.
>
> Hmm, that's not how I interpret the POSIX spec. Here are some
> excerpts from section 13.2, "Scheduling Policies". That's in the
> chapter which describes all of the sched_XXX() functions.
>
> This model discusses only processor scheduling for runnable
> threads ...
>
> There is, conceptually, one thread list for each priority. Any
> runnable thread may be on any thread list. Multiple scheduling
> policies shall be provided. Each nonempty thread list is
> ordered, contains a head as one end of its order, and a tail as
> the other. The purpose of a scheduling policy is to define the
> allowable operations on this set of lists.
>
> Each process shall be controlled by an associated scheduling
> policy and priority. These parameters may be specified by
> explicit application execution of the sched_setscheduler() or
> sched_setparam() functions.
>
> Each thread shall be controlled by an associated scheduling
> policy and priority. These parameters may be specified by
> explicit application execution of the pthread_setschedparam()
> function.
So far I read this as saying the sched_XXX functions operate
on processes, whereas the pthread_{set|get}schedparam
functions operate on threads.
>
> And then in the discussion of the SCHED_FIFO scheduling policy in
> section 13.2.1, it says:
>
> (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.
> (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).
> ...
>
> 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.
--
Dan Eischen
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SUN.3.91.1001014234955.25430B-100000>