我正试图在Linux下在<1 ms内完成一项任务，以满足软实时要求。 目前我正在使用带有4-8个线程的pthreads来尝试实现这一目标，但是看起来linux下的pthreads开销和延迟似乎并不适合短时间任务（ pthread_create和pthread_join +奇怪的非确定性行为，而线程正在运行，可以增加100-200μs更多）。
所以我想知道是否有其他方法可靠地运行短asynchronous任务，并具有相当低的延迟。 任务通常<500微秒，我需要他们在1毫秒内完成。 我可以直接以某种方式直接使用内核线程（kthreads）（例如使用共享内存作为任务数据）？ 或者可能是基于中断的东西？
我已经尝试在Linux上使用pthreads调度选项。 无论线程的优先级如何， SCHED_FIFO和SCHED_RR都会使事情变得更糟。 设置线程关联（ pthread_set_affinity_np ）虽然有点帮助，但是可以减less线程之间的线程迁移。
当前的代码也已经在Mac OS X（基于BSD和Mach内核）上testing过了 – 它可以很好地工作在pthread上，并且很容易满足<1 ms的要求。
看来Linux上的pthreads对于短时线程来说并不是很好的优化。 根据这篇文章： “Linux调度程序：一个浪费的核心十年” – Linux上的pthreads有许多问题，这似乎是由于在Linux调度程序中引入了多核心支持的随意方式。 我的问题似乎并没有与论文中提到的四个问题中的任何一个有关，但它确实暗示Linux上的线程可能是一个策略的蛋。
听起来像所有你需要的是一个线程池。 您可以使用长时间运行的工作线程从队列中执行任务，例如多生产者 – 多用户模式，而不是为每个任务创建/销毁线程。
我将从英特尔TBB任务计划程序开始 。
任务需要在Linux下<1 ms内完成
看，这似乎不是一个非常严格的要求。 有很多低延迟的财务软件面对更严格的要求。
在互联网上有很多关于编写低延迟软件的建议，例如：
既然你提到在你的问题中创建和删除线程，我想你打破了这些推荐（保持上下文切换到最低限度） 。 我想你应该保持一个或几个线程忙等待，而不是创建和加入。