Bug 89066

Summary: Can not set thread priority using shared library version of glibc/pthreads
Product: [Retired] Red Hat Linux Reporter: Arun Singh <arun_singh>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED WONTFIX QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 9CC: fweimer, shuston
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-21 23:20:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
Program to change the priority of a thread none

Description Arun Singh 2003-04-17 03:49:02 UTC
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-17 03:59:12 UTC
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 18:53:16 UTC
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 21:36:34 UTC
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 23:20:07 UTC
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 17:25:00 UTC
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.