防止Linux线程被调度程序中断

发布于 2024-08-28 05:19:08 字数 161 浏览 9 评论 0原文

如何告诉 Linux 中的线程调度程序不要因任何原因中断你的线程?我正在用户模式下编程。简单地锁定互斥体就可以完成这个任务吗?我想防止在执行某个函数时调度进程中的其他线程。它们会阻塞,而我会因为上下文切换而浪费 CPU 周期。我希望执行该函数的任何线程都能够在不中断的情况下完成执行,即使超出了线程的时间片。

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.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

悲歌长辞 2024-09-04 05:19:09

如何告诉 Linux 中的线程调度程序不要因任何原因中断线程?

这实际上是不可能的,你需要一个实时系统。使用 Linux 最重要的是
将调度策略设置为实时调度程序,例如SCHED_FIFO,并设置PTHREAD_EXPLICIT_SCHED 属性。请参阅此处,即使现在,例如 irq 处理程序和其他东西将中断您的线程并运行。

但是,如果您只关心自己进程中的线程无法执行任何操作,那么是的,让它们阻塞在您正在运行的线程持有的互斥体上就足够了。

困难的部分是每当您的线程需要执行其操作时协调所有其他线程以获取该互斥体。

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.

述情 2024-09-04 05:19:09

您应该构建您的软件,以便您依赖于调度程序从您的应用程序的角度做“正确”的事情。调度器很复杂。它会做它认为最好的事情。

上下文切换很便宜。你说

我会因为上下文切换而浪费 CPU 周期。

但你不应该这样看。使用互斥体和阻塞/等待进程的多线程机制。机器就在那里供你使用...

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...

小女人ら 2024-09-04 05:19:09

你不能。如果可以的话,什么可以防止您的线程永远不会释放请求并使其他线程挨饿。

您能做的最好的事情就是设置线程优先级,以便调度程序比优先级较低的线程更喜欢它。

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.

无所谓啦 2024-09-04 05:19:09

为什么不简单地让竞争线程阻塞,那么调度程序除了您的活动线程之外就没有什么可以调度的了?为什么要对调度程序进行二次猜测而使设计复杂化?

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?

背叛残局 2024-09-04 05:19:09

研究Linux下的实时调度。我从来没有这样做过,但如果您确实需要这样做,那么这是您在用户应用程序代码中可以获得的最接近的结果。

不过,你看起来害怕的事情其实并没有那么严重。您无法阻止内核因真正的中断或想要运行的更高优先级任务而中断您的程序,但是通过定期调度,内核确实使用它自己计算的优先级值,该值几乎可以处理您担心的大部分问题。如果线程 A 独占资源 X(X 可以是锁)并且线程 B 正在等待资源 X 变得可用,则 A 的有效优先级将至少与 B 的优先级一样高。它还会考虑进程是否使用大量 CPU 或者是否花费大量睡眠时间来计算优先级。当然,美好的价值也在那里。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文