Subj : Re: pthread priority in Linux 2.4 Kernel
To   : comp.programming.threads
From : David Schwartz
Date : Tue Aug 02 2005 03:18 pm


"forSale" <@hotmail.com> wrote in message 
news:sJKdnXR27uTxQ3LfRVn-pg@magma.ca...

> In real-time system, lower prority thread never runs util the
> higher priority thread is blocked

    That is not quite true. If, for example, you have two virtual CPUs, then 
both threads will run at the same time.

> .. I know Linux is not a real-time system
> however pthread claims SCHED_FIFO as real-time scheduler. I have modifed 
> my
> code, in my new code the  low priorty thread prints data on the screen and
> high priorty task does some number crunching. Now in real-time system the
> low priority task should never get the schedule time.

    No. Again your assumptions is just wrong. It is not true that a low 
priority task will never get schedule time. A low priority task will not get 
schedule time if, and only if, there is a higher priority task that is ready 
to run at that time, and there is only one execution unit available.

> It doesnt seem that
> way in Linux .. Let me know if you have tried thread priority test before
> and how would you prove pthread priority scheme is working

    I don't know enough about your application to give you that kind of 
advice. One way might be to create three threads. The first thread, at 
lowest priority, spins on code that does this: acquire mutex, increment 
count, release mutex. The second thread, at higher priority, spins on code 
that acquires a different mutex, increments a different counter, and 
releases the mutex. The third thread, at highest priority, sleeps for 10 
seconds, grabs both mutexes, and dumps both counts. One would expect the 
counter for the higher priority thread to be larger than for the lowest 
priority thread. One would expect the highest priority thread to be able to 
get the mutex from the lower priority threads.

    DS

.