Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 14 Oct 2000 13:00:43 -0700 (PDT)
From:      jdp@polstra.com
To:        current@freebsd.org
Cc:        eischen@vigrid.com
Subject:   Re: Recent thread changes
Message-ID:  <200010142000.e9EK0hn47439@vashon.polstra.com>
In-Reply-To: <Pine.SUN.3.91.1001014091525.13283A-100000@pcnet1.pcnet.com>
References:  <Pine.SUN.3.91.1001014091525.13283A-100000@pcnet1.pcnet.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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:
> > In article <200010132232.SAA05650@pcnet1.pcnet.com>,
> > Daniel Eischen  <eischen@vigrid.com> wrote:
> > > The range of valid priorities has also changed, perhaps
> > > requiring a library version bump.  The range of valid priorities
> > > is not visible outside of the threads library.  The only
> > > way it can be determined is through trial and error, so
> > > it _shouldn't_ be an issue.
> > 
> > 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.

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.

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

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

	...

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

John
-- 
  John Polstra                                               jdp@polstra.com
  John D. Polstra & Co., Inc.                        Seattle, Washington USA
  "Disappointment is a good sign of basic intelligence."  -- Chögyam Trungpa



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?200010142000.e9EK0hn47439>