Bug 89066 - Can not set thread priority using shared library version of glibc/pthreads
Can not set thread priority using shared library version of glibc/pthreads
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
9
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-04-16 23:49 EDT by Arun Singh
Modified: 2016-11-24 10:23 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-04-21 19:20:07 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Program to change the priority of a thread (3.30 KB, text/plain)
2003-04-16 23:59 EDT, Arun Singh
no flags Details

  None (edit)
Description Arun Singh 2003-04-16 23:49:02 EDT
Description of problem:
When I use pthread_attr_setschedparam(...) to set priority of a
thread, it does not take effect after the thread is created.
This problem is seen when I link my code with the shared library
version of libpthread. The output of ldd shows
# ldd a.out
        libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40028000)
        librt.so.1 => /lib/tls/librt.so.1 (0x40036000)
        libc.so.6 => /lib/tls/libc.so.6 (0x42000000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

It works fine when I link with the static version of the library.

Version-Release number of selected component (if applicable): glibc-2.3.2-27.9

How reproducible: Every Time

Steps to Reproduce:
1. Compile the attached source code: gcc a.c -lpthread
2. Run it as root, it will show that priority of the thread is 0
3. Compile it statically and run it, the priority will be set properly
   gcc -static a.c -lpthread

Actual results:
# ./thr-a.out
a.c:51 Sched prio = 50
a.c:60 Sched prio = 50
a.c:110 Thread[tid = 0x40849d30]
a.c:116 Thread sched policy = 0, prio = 0 <-- problem is here
a.c:133 Setting thread schedpolicy = 1, prio = 50
a.c:146 policy = 1, prio = 50
a.c:69 Created thread tid = 0x40849d30
a.c:71 Before join
a.c:76 After join 1


Expected results:
# ./a.out
a.c:51 Sched prio = 50
a.c:60 Sched prio = 50
a.c:110 Thread[tid = 0x4002]
a.c:116 Thread sched policy = 1, prio = 50
a.c:155 Thread priority is as expected
a.c:69 Created thread tid = 0x4002
a.c:71 Before join
a.c:76 After join 1

Additional info:
Comment 1 Arun Singh 2003-04-16 23:59:12 EDT
Created attachment 91168 [details]
Program to change the priority of a thread

Compile this program on Redhat Linux 9 and link it statically and dynamically.
When you run this program, the results are different. The dynamically linked
program is not able to set the thread priority correctly.
The statically linked program sets the priority properly.
Comment 2 Ulrich Drepper 2003-04-17 14:53:16 EDT
The new thread code does not support thread priorities since it's pointless. 
The necessary kernel interfaces don't exist.  At some point there might be a
variant of the thread library with the necessary support but the current
behavior is as designed.  No bug.
Comment 3 Arun Singh 2003-04-17 17:36:34 EDT
1. pthread_attr_setschedparam(...) is a POSIX standard interface function.
   What do you mean by "thread priorities are pointless"? If it does not
   make sense then why are we still able to set thread priority through
   pthread_setschedparam(...) function call from inside the thread?

2. If kernel interfaces do not exist why does setting the priority work
   when we use the pthreads static library? The behavior should be identical
   with both the static or dynamic library. Either it should work or it should
   not work.
Comment 4 Ulrich Drepper 2003-04-21 19:20:07 EDT
What I wrote is very clear, you simply are unwilling to read it:

The interfaces are pointless since the kernel is missing the support.  This is
not the normal priority code which is there, but the wakeup from the kernel
functionality which is used to implement the synchronization primitives.

All the RT stuff is 100% optional.  Therefore an implementation is not buggy if
it does not provide the support.  There is no bug.  Closed.
Comment 5 Steve Huston 2003-12-29 12:25:00 EST
But the implementation is buggy if it reports success when requested 
functionality is not implemented. In the original attached program, 
for example, when run by a non-root user, will silently fail the 
request to set SCHED_FIFO policy. The man page says it will fail with 
ENOTSUP. So this is a bug.

If the requested functionality (RT behavior) is really not 
implemented at all, then you should not define 
_POSIX_THREAD_PRIORITY_SCHEDULING and should refuse the request with 
ENOSYS.

Note You need to log in before you can comment on or make changes to this bug.