小编Bre*_*ett的帖子

我有一个用于嵌入式系统 ( foo.c, foo.h)的 C 模块，其中包含一个my_driver_fn()从 API 角度来看局部范围的函数（例如，不在foo的公共标头中：任何其他使用其 API 的代码#include "foo.h" 都不应被允许调用此函数）。假设my_driver_fn()是可重入的。

然而，foo使用一个libdostuff需要用一些用户提供的回调函数（架构/硬件特定的东西）初始化的库才能在任何平台上正常工作。在 中foo，my_driver_fn上面提到的将是有问题的功能之一......需要libdostuff，但不是任何使用foo.

对于这些回调函数（my_driver_fn()被声明为staticinside foo.c？鉴于它的地址被提供给libdostuff并且它是“间接地”调用（虽然从不直接）？

注意：我碰巧同时写了fooand libdostuff，我想知道用户提供的函数extern在链接时被纯粹解析，或者通过libdostuff用户提供的回调表传递到初始化中是否更有意义函数（例如libdostuff_init(CallbackTable *user_callbacks)whereCallbackTable有一个将被初始化为指向的函数指针my_driver_fn）

我有一个实时的Linux桌面应用程序(用C编写),我们正在移植到ARM(4核Cortex v8-A72 CPU).在架构上,它结合了高优先级显式pthread(其中6个)和一对GCD(libdispatch)工作队列(一个并发和另一个串行).

我的担忧有两个方面:

• 我听说ARM没有超越x86的方式,因此我的4核已经是上下文切换以跟上我的6 pthreads(和后台进程).我应该从中得到什么样的性能损失？
  • 我听说我应该期望这些ARM上下文切换效率低于x86.真的吗？
  • 一些pthreads是针对相当罕见的事件的高优先级处理程序,这会改变前景吗？(即他们坐在select声明中)
• 我更大的担忧来自GCD在这个应用程序中的影响.我对GCD内部工作原理的理解是,它是一个与调度程序交互的动态扩展线程池,并将尝试添加更多线程以适应负载.在我看来,这对我的情景中的性能几乎完全是负面影响.(核心被完全消耗的系统中的IE)正确吗？