From owner-freebsd-current Sat Oct 14 13: 0:51 2000 Delivered-To: freebsd-current@freebsd.org Received: from wall.polstra.com (rtrwan160.accessone.com [206.213.115.74]) by hub.freebsd.org (Postfix) with ESMTP id BFDC937B66C for ; Sat, 14 Oct 2000 13:00:47 -0700 (PDT) Received: from vashon.polstra.com (vashon.polstra.com [206.213.73.13]) by wall.polstra.com (8.9.3/8.9.3) with ESMTP id NAA08497; Sat, 14 Oct 2000 13:00:44 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.0/8.11.0) id e9EK0hn47439; Sat, 14 Oct 2000 13:00:43 -0700 (PDT) (envelope-from jdp) Date: Sat, 14 Oct 2000 13:00:43 -0700 (PDT) From: jdp@polstra.com Message-Id: <200010142000.e9EK0hn47439@vashon.polstra.com> To: current@freebsd.org Reply-To: current@freebsd.org Cc: eischen@vigrid.com Subject: Re: Recent thread changes In-Reply-To: References: Organization: Polstra & Co., Seattle, WA Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG In article , Daniel Eischen wrote: > On Sat, 14 Oct 2000 jdp@polstra.com wrote: > > In article <200010132232.SAA05650@pcnet1.pcnet.com>, > > Daniel Eischen 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