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:
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.
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.
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.
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.
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.