From owner-freebsd-current Sat Oct 14 21:20:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from pcnet1.pcnet.com (pcnet1.pcnet.com [204.213.232.3]) by hub.freebsd.org (Postfix) with ESMTP id C9E9637B66D for ; Sat, 14 Oct 2000 21:20:41 -0700 (PDT) Received: (from eischen@localhost) by pcnet1.pcnet.com (8.8.7/PCNet) id AAA00063; Sun, 15 Oct 2000 00:20:21 -0400 (EDT) Date: Sun, 15 Oct 2000 00:20:11 -0400 (EDT) From: Daniel Eischen To: current@freebsd.org Subject: Re: Recent thread changes In-Reply-To: <200010142000.e9EK0hn47439@vashon.polstra.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sat, 14 Oct 2000 jdp@polstra.com wrote: > In article , > Daniel Eischen 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