prevent linux thread from being interrupted by scheduler

Question

How do you tell the thread scheduler in linux to not interrupt your thread for any reason? I am programming in user mode. Does simply locking a mutex acomplish this? I wa

Answer 1

You can't. If you could what would prevent your thread from never releasing the request and starving other threads.

The best you can do is set your threads priority so that the scheduler will prefer it over lower priority threads.

Answer 2

Look into real time scheduling under Linux. I've never done it, but if you indeed do NEED this this is as close as you can get in user application code.

What you seem to be scared of isn't really that big of a deal though. You can't stop the kernel from interrupting your programs for real interrupts or of a higher priority task wants to run, but with regular scheduling the kernel does uses it's own computed priority value which pretty much handles most of what you are worried about. If thread A is holding resource X exclusively (X could be a lock) and thread B is waiting on resource X to become available then A's effective priority will be at least as high as B's priority. It also takes into account if a process is using up lots of cpu or if it is spending lots of time sleeping to compute the priority. Of course, the nice value goes in there too.

Answer 3

How do you tell the thread scheduler in linux to not interrupt your thread for any reason?

Can't really be done, you need a real time system for that. The closes thing you'll get with linux is to set the scheduling policy to a realtime scheduler, e.g. SCHED_FIFO, and also set the PTHREAD_EXPLICIT_SCHED attribute. See e.g. here , even now though, e.g. irq handlers and other other stuff will interrupt your thread and run.

However, if you only care about the threads in your own process not being able to do anything, then yes, having them block on a mutex your running thread holds is sufficient.

The hard part is to coordinate all the other threads to grab that mutex whenever your thread needs to do its thing.

Answer 4

You should architect your sw so you're not dependent on the scheduler doing the "right" thing from your app's point of view. The scheduler is complicated. It will do what it thinks is best.

Context switches are cheap. You say

I would be wasting cpu cycles with context switches.

but you should not look at it that way. Use the multi-threaded machinery of mutexes and blocked / waiting processes. The machinery is there for you to use...

Answer 5

Why not simply let the competing threads block, then the scheduler will have nothing left to schedule but your living thread? Why complicate the design second guessing the scheduler?