Thread: priority changing : CPU time?

It's a system call, so it is not just a couple of instructions. The actual code to change the priority of is a simple pointer-to-structure update, with some checking around it. I'd say that on a reasonably modern processor, less than a microsecond for sure.

However, I'd question the validity of (often) switching thread priority - perhaps it should always be the higher priority then?

--
Mats

So, what you are saying is that you are not actually changing the priority very often, but you want to change it when you take the mutex? And how often does that ACTUALLY happen? Once an hour, once every five seconds, or some other number?

--
Mas

Originally Posted by mynickmynick

the Linux I am using is embedded with LinuxThreads instead of NPTL (unfortunately!!)

So process == thread aside from memory mapping.

Every 50 msec is pretty often, when you consider that the scheduling quanta is 10ms. I don't think this thread should be low priority at all.

--
Mats

Originally Posted by mynickmynick

i am talking of SCHED_FF or SCHED_RR threads

Do you mean SCHED_FIFO? SCHED_RR is definitely going to (potentially at least) run threads in a different order than strict priority - I think SCHED_FIFO does too, but in a different non-strict order.

--
Mats

Right. So I'm still 90% sure that having different priorities is the WRONG solution.

I bet one of your threads is really CPU intensive, another is IO-intensive, and the third one is just doing some other random things. This sort of scheme generally fails when the scheduler decides to schedule the tasks in a different way than you expect them to be scheduled. The way around that is to do your own scheduling enforcement [it still doesn't prevent some random process from getting in and doing stuff, but it allows you to control which of YOUR processes runs next]. The other option is to entirely disconnect the threads from each other, such as using pipes or message passing mechanisms that are (for all intents and purposes) lock-free.

--
Mats