Subj : Re: pthread priority in Linux 2.4 Kernel
To   : comp.programming.threads
From : forSale
Date : Tue Aug 02 2005 07:12 pm

Hi David,
I see what you are seeing. You are saying if  Linux runs on multipe virtual
CPUs, then each CPU can runs its a thread.Thus allowing all thread
regardless of its priroty to run concurrently. How do I control the virtual
CPU. How do I configure only 1 virtual CPU.
How do I know how many virtual CPU the current linux is running on.

         Thanks
             Ottawa
"David Schwartz" <davids@webmaster.com> wrote in message
news:dcoo00$10h$1@nntp.webmaster.com...
>
> "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
>
>

.