Bug 90462 - (SCHEDULER)pthread SCHED_FIFO doesn't work
(SCHEDULER)pthread SCHED_FIFO doesn't work
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-05-08 12:29 EDT by Need Real Name
Modified: 2007-04-18 12:53 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:40:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Need Real Name 2003-05-08 12:29:08 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.79 [en] (X11; U; Linux 2.4.18-4 i686)

Description of problem:
Even when logged in as root, the kernel doesn't support SCHED_FIFO scheduling. 
I see different behaviour with a simple pthreads test program when running with
the vanilla 2.4.20 kernel and the 2.4.20-8 kernel.  I am not confident enough
with my knowledge of pthreads to report this as a bug except when researching
the problem, I ran into the following quote at the URL

"The kernel used by RedHat 7.3 (2.4.18-4) is broken with respect to SCHED_FIFO
and SCHED_RR. The function sched_setscheduler() silently fails to have any
effect on this kernel. I suggest downloading and building a fresh 2.4.18 kernel.
Also, it would not hurt to send a complaint to RedHat -- silent failure of
real-time features is a bad thing!"

The following code behaves differently on 2.4.20 and 2.4.20-8:
#include <stdio.h>
#include <pthread.h>
#include <unistd.h>
#include <time.h>
#include <sys/stat.h>
#include <sys/types.h>
#include <signal.h>
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
static int threadnum=0;

void *myloop(void *foo)
  for (;;) {
    static int scnt;
    if (threadnum != 1) {
      printf("thread 1 is running\n");
      threadnum = 1;
    if (scnt++ > 10000000) {
      printf("thread 1 is going to sleep\n");
      scnt = 0;

void *myloop2(void *foo)
  for (;;) {
    static int scnt;
    if (threadnum != 2) {
      printf("thread 2 is running\n");
      threadnum = 2;
    if (scnt++ > 100000000) {
      printf("thread 2 is going to sleep\n");
      scnt = 0;


int main(int argc, char *argv[])

  pthread_attr_t attr2;
  pthread_attr_setschedpolicy(&attr2, SCHED_FIFO);
  struct sched_param param2;
  param2.sched_priority = sched_get_priority_max(SCHED_FIFO);
  pthread_attr_setschedparam(&attr2, &param2);
  pthread_attr_setdetachstate(&attr2, PTHREAD_CREATE_DETACHED);
  pthread_attr_setinheritsched(&attr2, PTHREAD_EXPLICIT_SCHED);
  pthread_t myThread2;
  if (pthread_create(&myThread2, &attr2, &myloop2, 0) != 0) {

  pthread_attr_t attr;
  pthread_attr_setschedpolicy(&attr, SCHED_FIFO);
  struct sched_param param;
  param.sched_priority = sched_get_priority_max(SCHED_FIFO)-1;
  pthread_attr_setschedparam(&attr, &param);
  pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
  pthread_attr_setinheritsched(&attr, PTHREAD_EXPLICIT_SCHED);
  pthread_t myThread;
  if (pthread_create(&myThread, &attr, &myloop, 0) != 0) {

  while (1) {


Specifically, thread 1 runs when the higher priority thread 2 is ready to run.

Version-Release number of selected component (if applicable):
kernel-2.4.20-8 and 2.4.18-4

How reproducible:

Steps to Reproduce:
1.Compile example code using: g++ -o testfifo testfifo.cc -lpthread
2.run it: ./testfifo

Actual Results:  thread 1 preempts the higher priority thread 2

Expected Results:  thread 1 runs only when thread 2 is sleeping

Additional info:
Comment 1 Bugzilla owner 2004-09-30 11:40:53 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

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