GNOME Bugzilla – Bug 604857
GThreadPriority levels for SCHED_RR threads are dysfunctional
Last modified: 2011-09-30 03:52:55 UTC
GThreadPriority priority level changes are dysfunctional in gthread-posix because of the two problems outlined below (in addition to the prerequisite bug 599079). Problem #1: If the current POSIX scheduling policy has been changed to anything besides the default SCHED_OTHER, bogus priority values get stuffed into the g_thread_priority_map[{LOW,NORMAL,HIGH,URGENT}] array. - The LOW and URGENT values come from POSIX_{MIN,MAX}_PRIORITY in config.h. But notice the hard-coded reference to "SCHED_OTHER"!... /* Maximum POSIX RT priority */ #define POSIX_MAX_PRIORITY sched_get_priority_max(SCHED_OTHER) /* Minimum POSIX RT priority */ #define POSIX_MIN_PRIORITY sched_get_priority_min(SCHED_OTHER) Those macros are not relevant if the scheduling policy has already been changed to anything besides SCHED_OTHER. - The NORMAL value gets set correctly from the current scheduling priority. - The HIGH value gets computed from the NORMAL and URGENT values by the macros near gthread-impl.c:55. Since URGENT is not correct, HIGH is not correct. So when a program run as "sudo chrt 50 ./program" calls g_thread_init(), the resulting g_thread_priority_map[] ends up mostly wrong: sudo ... gdb ... chrt 50 ./program (gdb) p g_thread_priority_map $1 = {0, 50, 16, 0} The bogus LOW and URGENT values of 0 (the SCHED_OTHER defaults) are actually illegal for SCHED_RR, where the valid range is 1 to 99. Problem #2 Even with the g_thread_priority_map[] problem corrected, any priority change just gets silently ignored by pthreads because the default "inheritance mode" is PTHREAD_INHERIT_SCHED. An attached demonstration program (test_rg_gthread2) which sets the GThreadPriority to G_THREAD_PRIORITY_URGENT shows the problem: PID POL RTPRIO LWP S TTY TIME COMMAND 13992 RR 50 13992 S pts/3 00:00:00 ./test_rt_gthread2 URGENT 13992 RR 50 13994 S pts/3 00:00:00 ./test_rt_gthread2 URGENT ^^ <-- this "RR 50" should be "RR 99" To enable pthread priority changes, the pthreads inheritance mode must be set to PTHREAD_EXPLICIT_SCHED.
Created attachment 149937 [details] demonstration program: test_rt_gthread2
Created attachment 149941 [details] [review] [PATCH] Fix GThreadPriority handling for sched policy != SCHED_OTHER Correct the bogus g_thread_priority_map[] priority value computations. Allow priority changes to actually work by enabling PTHREAD_EXPLICIT_SCHED inheritance. Pre-requires the patch for https://bugzilla.gnome.org/show_bug.cgi?id=599079 . Fixes https://bugzilla.gnome.org/show_bug.cgi?id=604857 .
After patching, the g_thread_priority_map[] values are correct: sudo ... gdb ... chrt 50 ./program (gdb) p g_thread_priority_map $1 = {1, 50, 82, 99} sudo ... gdb ... chrt 10 ./program (gdb) p g_thread_priority_map $1 = {1, 10, 69, 99} And a G_THREAD_PRIORITY_URGENT thread does get run with the proper elevated SCHED_RR priority: sudo chrt 50 ./test_rt_gthread2 URGENT PID POL RTPRIO LWP S TTY TIME COMMAND 13985 RR 50 13985 S pts/3 00:00:00 ./test_rt_gthread2 URGENT 13985 RR 99 13987 S pts/3 00:00:00 ./test_rt_gthread2 URGENT ^^ ^^ <--- correct
thread priorities have been deprecated