For some reason the above function doesn't work in linux no matter what priority is used or what thread id is given yet it works perfectly in MacOS. Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to allow priority setting to work?
Here's some example test code:
#include <stdio.h>
#include <stdlib.h>
#include <pthread.h>
#include <string.h>
#include <errno.h>
void info()
{
struct sched_param param;
pthread_t tid = pthread_self();
int policy;
if (pthread_getschedparam(tid,&policy,¶m)) abort();
printf("Policy = %d, priority = %d\n",policy,param.sched_priority);
}
void setPriority(pthread_t tid)
{
struct sched_param param;
int cnt = 0;
int i;
for(i=1;i < 100;++i)
{
param.sched_priority = i;
if (pthread_setschedparam(tid,SCHED_FIFO,¶m))
{
printf("%d: %d,%s\n",i,errno,strerror(errno));
++cnt;
}
else printf("%d: SUCCESS\n",i);
}
printf("%d failures.\n",cnt);
}
void *func(void *p)
{
pthread_t tid = pthread_self();
puts("Child thread:");
info();
setPriority(pthread_self());
return NULL;
}
int main()
{
pthread_t tid;
pthread_attr_t attr;
puts("Parent thread:");
setPriority(pthread_self());
puts("---------------");
pthread_attr_init(&attr);
pthread_attr_setinheritsched(&attr,PTHREAD_EXPLICIT_SCHED);
if (pthread_create(&tid,&attr,func,NULL) == -1) abort();
pthread_join(tid,NULL);
return 0;
}
For some reason the above function doesn't work in linux no matter what priority is used or what thread id is given yet it works perfectly in MacOS. Also on Linux using pthread_getschedparam() just returns a priority of
zero.
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what
priority is used or what thread id is given yet it works perfectly in MacOS. >> Also on Linux using pthread_getschedparam() just returns a priority of
zero.
It works when run as root. In general, since threads a essentially
processes, you don't want any old code to be setting their priority.
There may be a less heavy-handed way to achieve what you want, but I
can't say what off the top of my head.
On Linux, there are different schedulers and thread is just another process, >that shares same memory space. I would try process scehduling functions...
On Thu, 25 Nov 2021 15:37:07 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what
priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of
zero.
It works when run as root. In general, since threads a essentially
Not for me.
On Linux, there are different schedulers and thread is just another process, that shares same memory space.
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>priority is used or what thread id is given yet it works perfectly in MacOS. >>>Also on Linux using pthread_getschedparam() just returns a priority of zero. >>>
Anyone know why? Is there some attribute that needs to be set on Linux to >>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities within the OS.
For some reason the above function doesn't work in linux no matter what >priority is used or what thread id is given yet it works perfectly in MacOS. >Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >allow priority setting to work?
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>priority is used or what thread id is given yet it works perfectly in MacOS. >>Also on Linux using pthread_getschedparam() just returns a priority of zero. >>
Anyone know why? Is there some attribute that needs to be set on Linux to >>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>>priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >>>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities >> within the OS.
I think your information (or your Linux) is out of date. Threads are >scheduled by the kernel in the same way as processes (in effect they are >processes), though the whole topic is very complicated. (For example,
the prioroty can be set to relative to a thread group. I don't pretend
to know the ins and outs.)
In sched(7) you will find:
According to POSIX.1, the nice value is a per-process attribute; that
is, the threads in a process should share a nice value. However, on
Linux, the nice value is a per-thread attribute: different threads in
the same process may have different nice values.
On Sat, 27 Nov 2021 17:05:07 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>>>priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >>>>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities
within the OS.
I think your information (or your Linux) is out of date. Threads are >>scheduled by the kernel in the same way as processes (in effect they are >>processes), though the whole topic is very complicated. (For example,
the prioroty can be set to relative to a thread group. I don't pretend
to know the ins and outs.)
In sched(7) you will find:
According to POSIX.1, the nice value is a per-process attribute; that
is, the threads in a process should share a nice value. However, on
Linux, the nice value is a per-thread attribute: different threads in
the same process may have different nice values.
Fair enough. Still doesn't explain why the function in the subject line doesn't
work no matter what value you give it.
Also its valid value range doesn't
match that of process priorities.
On Thu, 25 Nov 2021 15:37:07 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what
priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of
zero.
It works when run as root. In general, since threads a essentially
Not for me.
On 11/25/21 10:55 AM, DozingDog@thekennel.co wrote:
On Thu, 25 Nov 2021 15:37:07 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>> priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of >>>> zero.
It works when run as root. In general, since threads a essentially
Not for me.
Since it works for Ben, and doesn't work for you, an important question
that only you can answer is, how does it fail for you?
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>priority is used or what thread id is given yet it works perfectly in MacOS. >>>Also on Linux using pthread_getschedparam() just returns a priority of zero. >>>
Anyone know why? Is there some attribute that needs to be set on Linux to >>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities >within the OS.
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 17:05:07 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>>>>priority is used or what thread id is given yet it works perfectly in >MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of >zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >>>>>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only >>>>>a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process >priorities
within the OS.
I think your information (or your Linux) is out of date. Threads are >>>scheduled by the kernel in the same way as processes (in effect they are >>>processes), though the whole topic is very complicated. (For example, >>>the prioroty can be set to relative to a thread group. I don't pretend >>>to know the ins and outs.)
In sched(7) you will find:
According to POSIX.1, the nice value is a per-process attribute; that
is, the threads in a process should share a nice value. However, on
Linux, the nice value is a per-thread attribute: different threads in
the same process may have different nice values.
Fair enough. Still doesn't explain why the function in the subject line >doesn't
work no matter what value you give it.
Since it worked for me (under sudo) I am not sure what needs explaining.
It did not work for you, but the details on that were very sparse.
Also its valid value range doesn't
match that of process priorities.
Did you read sched(7)? Does the process have suitable privileges?
On 11/25/21 10:55 AM, DozingDog@thekennel.co wrote:
On Thu, 25 Nov 2021 15:37:07 +0000
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>> priority is used or what thread id is given yet it works perfectly in >MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of >>>> zero.
It works when run as root. In general, since threads a essentially
Not for me.
Since it works for Ben, and doesn't work for you, an important question
that only you can answer is, how does it fail for you?
It's permitted to fail. If it does, it should return a non-zero value
and set errno to either ENOTSUP or EINVAL. If you change your call to
if(pthread_attr_setinheritsched(&attr,PTHREAD_EXPLICIT_SCHED)){
perror("pthread_attr_setinheritsched");
}
What results do you get?
The kind of program that needs to call that function is likely to be
very complicated, but if you can simplify the program down to a small,
compileable program that demonstrates what went wrong, and then tell us >precisely what results you got from running that program, it would make
it a lot easier for people to help you.
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>>priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >>>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities >>within the OS.
As was pointed out to you, linux threads are light-weight processes >implemented as an 1:1 threading model.
The last M:N threading model I worked with was Unixware, and even there,
a thread couldn't have a priority higher than the process priority
unless it was part of a privileged process.
Leaving aside the details, allowing arbitrary control of the priority
of schedulable entities is rather unfriendly on a multiuser or multi
tenant system.
It's permitted to fail. If it does, it should return a non-zero value >[pthread_attr_setinheritsched is] permitted to fail. If it does, it should return a non-zero value
and set errno to either ENOTSUP or EINVAL. If you change your call to
if(pthread_attr_setinheritsched(&attr,PTHREAD_EXPLICIT_SCHED)){
perror("pthread_attr_setinheritsched");
}
On Sun, 28 Nov 2021 00:19:36 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>>>priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >>>>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only
a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities >>>within the OS.
As was pointed out to you, linux threads are light-weight processes >>implemented as an 1:1 threading model.
They're still within the same process with the same process ID.
The last M:N threading model I worked with was Unixware, and even there,
a thread couldn't have a priority higher than the process priority
unless it was part of a privileged process.
Leaving aside the details, allowing arbitrary control of the priority
of schedulable entities is rather unfriendly on a multiuser or multi
tenant system.
I was under the impression that setting a threads priority set the
priority of thread IN THAT PROCESS, it didn't set the priority of the
thread wrt the OS. The latter is the "nice" level.
On 11/29/21 5:14 AM, DozingDog@thekennel.co wrote:
On Sat, 27 Nov 2021 16:44:17 -0500....
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
compileable program that demonstrates what went wrong, and then tell us
precisely what results you got from running that program, it would make
it a lot easier for people to help you.
I did, that was the test code.
Sorry. I've given out that advice so often that I just wrote it out
without stopping to think about the parts that weren't relevant to your
case. However, you didn't complete the last part: you didn't tell us
what results you actually got. You only told us that it didn't work.
If you're no longer interested in this issue, feel free to ignore my
request. However, keep in it mind the next time you ask for help: you
should always include the unexpected output that you observed, if you
can, along with an explanation of what it was you did expect (often,
it's your expectations that are incorrect, rather than the output of the
code - and sometimes both need correction).
DozingDog@thekennel.co writes:
I was under the impression that setting a threads priority set the
priority of thread IN THAT PROCESS, it didn't set the priority of the >>thread wrt the OS. The latter is the "nice" level.
That depends on the threading model (1:1 vs. M:N) - in the later, there
is a user-level scheduler which is constrained by the process priority;
in the former, each thread is scheduled by the kernel. Experience with >SVR4.2 ES/MP (and subsequently Unixware 2) showed that a user-level scheduler >was complicated and provided little, if any, performance benefit.
On Sat, 27 Nov 2021 20:48:22 +0000...
Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
Since it worked for me (under sudo) I am not sure what needs explaining.
It did not work for you, but the details on that were very sparse.
Thats because I don't have many.
On Sat, 27 Nov 2021 16:44:17 -0500...
James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
compileable program that demonstrates what went wrong, and then tell us
precisely what results you got from running that program, it would make
it a lot easier for people to help you.
I did, that was the test code.
Anyway, I no longer have to worry about it but thanks for the help.
On Mon, 29 Nov 2021 14:44:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
I was under the impression that setting a threads priority set the >>>priority of thread IN THAT PROCESS, it didn't set the priority of the >>>thread wrt the OS. The latter is the "nice" level.
That depends on the threading model (1:1 vs. M:N) - in the later, there
is a user-level scheduler which is constrained by the process priority;
in the former, each thread is scheduled by the kernel. Experience with >>SVR4.2 ES/MP (and subsequently Unixware 2) showed that a user-level scheduler >>was complicated and provided little, if any, performance benefit.
Its not about performance benefits, its more a case of sensible resource >utilisation. Eg: if I have 2 threads, one doing CPU bound calculations and >the other flashing a cursor and occasionally dealing with user input then I'd >want the former to have higher priority IN THE PROCESS than the latter.
Eg: if I have 2 threads, one doing CPU bound calculations and
the other flashing a cursor and occasionally dealing with user input then I'd want the former to have higher priority IN THE PROCESS than the latter.
DozingDog@thekennel.co writes:
On Sun, 28 Nov 2021 00:19:36 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
On Sat, 27 Nov 2021 16:27:11 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
For some reason the above function doesn't work in linux no matter what >>>>>>priority is used or what thread id is given yet it works perfectly in MacOS.
Also on Linux using pthread_getschedparam() just returns a priority of zero.
Anyone know why? Is there some attribute that needs to be set on Linux to >>>>>>allow priority setting to work?
An unprivileged process can only reduce (lessen) its priority. Only >>>>>a privileged process can raise (increase) its priority.
I'm talking about thread priorities within a process, not process priorities
within the OS.
As was pointed out to you, linux threads are light-weight processes >>>implemented as an 1:1 threading model.
They're still within the same process with the same process ID.
They are independently scheduled by the kernel. From the kernel
point of view, they are separate processes sharing an address space
and some process-global data. Technically, they're "clone" processes.
Why don't you _reduce_ the priority of the cpu bound thread then? That's always nice and legal (pun intended).
scott@slp53.sl.home (Scott Lurndal) writes:
They are independently scheduled by the kernel. From the kernel
point of view, they are separate processes sharing an address space
and some process-global data. Technically, they're "clone" processes.
Separate processes sharing an address space is a contradictio in
adiecto as the definition of process is
An address space with one or more threads executing within that
address space, and the required system resources for those
threads.
That's not consistent with the historic, empirical definition of process
as a certain kernel-level abstraction which exists in
UNIX-the-program. But applying that to Linux makes no sense as Linux is
not something derived from the UNIX codebase. The Linux term is "kernel
DozingDog@thekennel.co, dans le message <so30ae$1e8j$1@gioia.aioe.org>,
a écrit :
Eg: if I have 2 threads, one doing CPU bound calculations and
the other flashing a cursor and occasionally dealing with user input then I'd
want the former to have higher priority IN THE PROCESS than the latter.
AFAIK, the scheduler of modern operating systems already does that >automatically: it identifies CPU-bound and interactive processes and gives >higher priority to interactivity.
DozingDog@thekennel.co writes:
On Mon, 29 Nov 2021 14:44:21 GMT
scott@slp53.sl.home (Scott Lurndal) wrote:
DozingDog@thekennel.co writes:
I was under the impression that setting a threads priority set the >>>>priority of thread IN THAT PROCESS, it didn't set the priority of the >>>>thread wrt the OS. The latter is the "nice" level.
That depends on the threading model (1:1 vs. M:N) - in the later, there >>>is a user-level scheduler which is constrained by the process priority; >>>in the former, each thread is scheduled by the kernel. Experience with >>>SVR4.2 ES/MP (and subsequently Unixware 2) showed that a user-level scheduler
was complicated and provided little, if any, performance benefit.
Its not about performance benefits, its more a case of sensible resource >>utilisation. Eg: if I have 2 threads, one doing CPU bound calculations and >>the other flashing a cursor and occasionally dealing with user input then I'd >>want the former to have higher priority IN THE PROCESS than the latter.
Why don't you _reduce_ the priority of the cpu bound thread then? That's >always nice and legal (pun intended).
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 75:06:08 |
| Calls: | 6,657 |
| Calls today: | 3 |
| Files: | 12,203 |
| Messages: | 5,332,640 |
| Posted today: | 1 |