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 want to prevent other threads in my process from being scheduled when a certain function is executing. They would block and I would be wasting cpu cycles with context switches. I want any thread executing the function to be able to finish executing without interruption even if the threads' timeslice is exceeded.
20
votes
Hi thanks for all the comments. I think I learned the answer, which is NO. The reason I asked was: Our app spends a lot of time in IO wait states because it accesses 500 GB worth of data files that change hourly. I want to use lots of threads to perform parallel IO (yes the filers can handle it...they are already handling IO from 3200 instances of app and this is not to handle more work, but to shorten the wall time). Our boxes are all MP with 8-64 "CPUs" counting actual cores and hyperthreading...so I can have a lot of threads running simultaneously.
– johnnycrash
Parallell IO usually degrades performance, it can be quite considerable. A drive can't do stuff in parallel(beyond a certain point depending on your raid setup). If you want to maximise performance, you'd want a handful IO threads feeding (as large as possible) data to/from worker threads.
– leeeroy
Look into aio.h. Asynchronous Input Output @leeeroy Parallell IO can be a win since it allows the block device scheduler to actually have things to schedule and make better use of the sweeps of the disk read/write heads. Plus drives have their own cache and do their own scheduling. Either way, AIO should get that benifit too.
– nategoose
5 Answers
17
votes
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.
3
votes
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...
1
votes
1
votes
1
votes
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.
