From owner-freebsd-current Mon Oct 16 19: 1:42 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 0555C37B4E5 for ; Mon, 16 Oct 2000 19:01:36 -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 TAA19753; Mon, 16 Oct 2000 19:01:17 -0700 (PDT) (envelope-from jdp@wall.polstra.com) Received: (from jdp@localhost) by vashon.polstra.com (8.11.0/8.11.0) id e9H21GF53460; Mon, 16 Oct 2000 19:01:16 -0700 (PDT) (envelope-from jdp) Date: Mon, 16 Oct 2000 19:01:16 -0700 (PDT) From: jdp@polstra.com Message-Id: <200010170201.e9H21GF53460@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: > 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 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