priority changing : CPU time?

Could you suggest some relevant tests for CPU time necessary for temporarily changing thread priority?? (links or figures)
Thank you

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

Quote:

---

Originally Posted by matsp

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

---

it is related to the other thread we discussed about (priority inversion due to lock/unlock)
so this dynamical change of priority would happen not so often (well not even rarely..)

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

Quote:

---

Originally Posted by matsp

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

---

say once every 50 msec (more or less)

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

Quote:

---

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

i am talking of SCHED_FF or SCHED_RR threads

Quote:

---

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

Quote:

---

Originally Posted by matsp

Do you mean SCHED_FIFO? --
Mats

---

yes!

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