threads in real-time scheduling - help needed

threads in real-time scheduling - help needed

Post by Michal Szymans » Sat, 21 Apr 2001 07:48:48


I'm experimenting a bit with threaded application in real time
scheduling policy.

I'm having problems with getting the two threads share the CPU time.
In the short program included below, I set the scheduling policy
of the parent thread to SCHED_RR with priority of 10. Then a child
thread is created with optionally inherited scheduling policy

The effect is following:

1. when run without root priviledges the scheduling setting calls fail
(of course) and the two threads share the CPU time - 'nc' grows
up to MAX, 'nf' contains some big number at exit. As expected.

With root priviledges, I get:

2. when the created child thread does not inherit scheduling policy
from the parent (thus getting default SCHED_OTHER - non RT policy),
only main thread is executing until alarm signal is delivered.
This is also expected behaviour.

3. when the created child thread *does* inherit scheduling policy
(by running the command with any command line argument),
I always get "nc=MAX nf=0 flag=1" final output. This means that
although in principle both parent and child threads have the same
round-robin scheduling policy and both "while" loops attempt
to yield CPU after every loop execution, it does not work
- the child thread does the whole while loop in just one time slice.
Only when I make MAX much bigger, a single time slice is not enough
to perform the whole loop and I get nonzero "nf" counter.

Is there any way to yield CPU between such threads effectively?

The best thing that I'd like to do would be (in the future real
application) to make the parent thread sleep after doing its job in
every loop, thus letting the child thread work. The problem is that the
parent thread will have to check some external device status about every
20ms. This, unfortunately, is just about the lower limit on the time one
can "sleep" in Linux (10ms clock tick plus up to another 10ms of
unpredictable delay). I know that RT apps can nanosleep up to 2ms with
microsecond accuracy, but this is done with so called busy-waits which
apparently do not free the CPU, so they are hardly useful for me.

any hints will be appreciated,

regards, Michal.


  Warsaw University Observatory, Warszawa, POLAND


#include <stdio.h>
#include <pthread.h>
#include <sched.h>
#include <sys/types.h>
#include <asm/timex.h>
#include <asm/bitops.h>
#include <signal.h>

#define MAX 1000000

void en(int *);
void to(int *);

int       r1=0;
int       r2=0;
pthread_t  t1, t2;
int flag=0, nc=0, nf=0;
unsigned long long cpuclock[MAX];

void sigalarm(int sig)
  printf("%d %d %d\n", nc, nf, flag);


main (int argc, char *argv[])
  struct sched_param sp;
  pthread_attr_t attr;
  int inherit=0;

  if ( argc > 1 ) inherit=1;
  sp.sched_priority = 10;
  pthread_setschedparam(pthread_self(), SCHED_FIFO, &sp);
  signal(SIGALRM, sigalarm);
  if ( inherit ) pthread_attr_setinheritsched(&attr, PTHREAD_INHERIT_SCHED);
  pthread_create(&t1, &attr, (void *)en, (void *) &r1);
  pthread_join(t1, NULL);
  printf("%d %d %d\n", nc, nf, flag);


void en(int *foo)
  unsigned long eax, edx;

  while ( nc < MAX ) {
    cpuclock[nc] = ((unsigned long long)(edx) << 32) + eax;
  set_bit(0, &flag);


void to(int *foo) {
  while ( !flag ) {


1. Mixed Time-Share & real-Time scheduling

 I seem to have this problem:

 Process Proc is started in real time, it in turns creates  THR_BOUND thrA.

 And then it drops itself in time share queue and creates THR_BOUND thrB.
(Actually there are a multitude of time-share and real-time threads.)

 Now thrA runs for a while (some milliseconds, say 15 ) and then it sleeps
for some milliseconds. (This is actually done by some interrupt mechanism
but that probably is not important either) and then thrB comes in prints some
data generated by thrA and goes to sleep. So far so good. Now however
if I go to another window and do an "ls" or another command, what I am
seeing is that if "ls" starts when the time-share thread thrB is running,
it can preempt thrB, and when the time to run thrA comes again, scheduler
doesn't necessarily run thrA. Soit appears that some piece of code
in the scheduler, when it gets a level 10 interrupt, it checks the
process table, and not the LWP table to find out if any real-time
LWPs are waiting or not. So if there is NO processes in real-time
queue, it assumes that there are no real-time LWPs waiting, and skips
that portion of the scheduler.... This is pure conjecture, but I am at
a loss to explain this behaviour. This can make me sometimes lose 10 or
20 milliseconds, invalidating houirs worth of run sometimes.
It works correctly if the process is in the real-time queue. Any
suggestions. (we got and tried patch -54 just to be sure...)


PS: platform is SS10/512MP

2. HP-Partition on MOD

3. Thread won't switch from real time scheduling policy to 'other'

4. ATAPI CDROM and unix 3.2 4.2 and UOD429A

5. Real-time Scheduling

6. SUSE 6.1 Permission differences between running a program from rc.d versus root

7. questions about poll(2) in real-time scheduling

8. Run program as another user

9. unix real-time scheduling?

10. real-time scheduling on unix?

11. Real-time Scheduling

12. 2.4-ac: real-time / scheduling information out of /proc

13. Solaris2.0/2.1 Real time "Fast" timing/scheduling