8 messages in org.freebsd.freebsd-currentRe: Recent thread changes| From | Sent On | Attachments |
|---|---|---|
| Daniel Eischen | Oct 13, 2000 3:32 pm | |
| jd...@polstra.com | Oct 14, 2000 3:08 am | |
| Daniel Eischen | Oct 14, 2000 6:33 am | |
| jd...@polstra.com | Oct 14, 2000 1:00 pm | |
| Daniel Eischen | Oct 14, 2000 9:19 pm | |
| Gerhard Sittig | Oct 15, 2000 3:38 am | |
| jd...@polstra.com | Oct 16, 2000 7:00 pm | |
| Daniel M. Eischen | Oct 16, 2000 7:33 pm |
| Subject: | Re: Recent thread changes | |
|---|---|---|
| From: | jd...@polstra.com (jd...@polstra.com) | |
| Date: | Oct 16, 2000 7:00:54 pm | |
| List: | org.freebsd.freebsd-current | |
In article <Pine...@pcnet1.pcnet.com>, Daniel Eischen <eisc...@vigrid.com> 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 jd...@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 majo...@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message