Re: Recent thread changes
In article
[EMAIL PROTECTED], Daniel
Eischen [EMAIL PROTECTED] 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 [EMAIL PROTECTED]
John D. Polstra Co., Inc.Seattle, Washington USA
"Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
[EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: 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. I tend to agree. When you consider that you can mix PTHREAD_SCOPE_SYSTEM threads with PTHREAD_SCOPE_PROCESS threads, it seems logical that you'd want the priority ranges in both the threads library and the kernel to agree. I would just rather see 0..31 instead of -20..20. We'll have to address this issue in the near future. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
On Sun, Oct 15, 2000 at 00:20 -0400, Daniel Eischen wrote: On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote: (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). Is this what was discussed some time ago as a DoS mechanism for Windows apps? Talk was about "calling setprio() in your running time slice will make you run again right away and starve anyone else" so it turned out to look like some modern kind of cooperative multitasking where one doesn't have to grant resources to others if one doesn't feel like it? Something good to have if you feel like getting all the CPU cycles ... virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: I've just committed some changes to the threads library and would appreciate feedback from anyone running threaded applications. They include fixes that -stable could really use. This commit also implements zero system call thread context switching in the threads library. Switching between threads is now much faster than before this change. This sounds like great stuff! 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? John -- John Polstra [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Recent thread changes
In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] wrote: On Sat, 14 Oct 2000 [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Daniel Eischen [EMAIL PROTECTED] 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 [EMAIL PROTECTED] John D. Polstra Co., Inc.Seattle, Washington USA "Disappointment is a good sign of basic intelligence." -- Chögyam Trungpa To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Recent thread changes
I've just committed some changes to the threads library and would appreciate feedback from anyone running threaded applications. They include fixes that -stable could really use. This commit also implements zero system call thread context switching in the threads library. Switching between threads is now much faster than before this change. At the end is a performance test for thread switches. The test program creates 10 threads that do nothing but pthread_yield(). Please realize that this is not an example of a typical application. Some applications may not see any noticeable improvement. 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. BTW, _PTHREADS_INVARIANTS is the default for a while until I'm sure there aren't any major problems. The performance hit should be negligible. Edit src/lib/libc_r/Makefile to turn it off. Before After - Thread 0 iterations: 35400 Thread 0 iterations: 259131 Thread 1 iterations: 35400 Thread 1 iterations: 259131 Thread 2 iterations: 35399 Thread 2 iterations: 259131 Thread 3 iterations: 35399 Thread 3 iterations: 259130 Thread 4 iterations: 35399 Thread 4 iterations: 259130 Thread 5 iterations: 35399 Thread 5 iterations: 259130 Thread 6 iterations: 35399 Thread 6 iterations: 259130 Thread 7 iterations: 35399 Thread 7 iterations: 259130 Thread 8 iterations: 35399 Thread 8 iterations: 259130 Thread 9 iterations: 35399 Thread 9 iterations: 259130 Total iterations: 353992 Total iterations: 2591303 real0m10.043sreal0m10.153s user0m3.558s user0m9.947s sys 0m6.445s sys 0m0.010s -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
