winapi - 我应该为 Windows Mobile RIL 使用 Mutex 还是临界区

Question

我在Windows Mobile 应用程序中使用Radio Layer Interface (RIL) Native APIs。在此 API 中，大多数函数的返回值/结果不会立即返回，而是通过回调函数传递给 RIL API。

在XDA 开发工具和Google Gears Geolocation API中可以找到一些使用示例。

我的问题是，在这两个示例中，互斥锁用于保护数据而不是其他同步对象。

现在，在这两个示例描述的用例中，关键部分在这里会做得很好吗？哪个线程或进程将实际调用回调函数？

编辑：
我的代码只能从我的进程内部访问我的数据，但是哪个线程/进程正在调用 RIL API 中的回调函数？我的意思是，我向 RIL API 传递了一个函数回调，但是这些回调是从其他进程调用的吗？在这种情况下，它将给出样本使用互斥锁的另一种解释。如果 RIL API 实际上在我的进程中创建了一个线程并调用了我的回调函数，那么我认为关键部分会很好（而且它比互斥锁更快）。

更新：
我有（1）我的代码从我自己的进程中访问的数据，并且还（2）从函数回调中修改。回调由 RIL API 完成。

我的问题：哪个线程/进程正在调用 RIL API 中的回调函数？

到目前为止的故事：
我：嗨，RIL 先生，请把一些数据放到我的办公室（又名变量）。
RIL：好的，先生。我稍后会放数据，完成后我会向您发出信号（我在这里使用了一个事件）。

进入我的办公室需要一张门禁卡。如果 RIL 先生和我来自同一家公司，RIL 先生可以使用他自己的访问卡进入我的办公室（在我的情况下，这意味着一个关键部分）。如果他来自其他公司，我需要为他设置一张门禁卡/访客卡（在我的情况下，我需要一个互斥锁）。

如果RIL先生使用他自己的门禁卡，这意味着我不需要为他设置门禁卡/访客卡，这对我来说意味着更少的麻烦。（即临界区比互斥锁快）

问题是，我几天前才认识了这位RIL先生，对他了解不多。我不知道他和我是不是同一个公司的。nobugz提到的一种选择是为 RIL 先生设置访问卡，无论 RIL 先生是否与我来自同一家公司。这样，RIL 先生就可以保证能够进入我的办公室。（我的数据/变量保证是安全的）

现在我在我的代码中使用互斥锁（为 RIL 先生设置一个可能冗余的访问卡）。

啊哈！写这篇文章的时候突然想到了。我想我会问 RIL 先生他来自哪家公司。这样以后如果他和我在同一家公司，我就不用给他设置门禁卡了。（即把GetCurrentProcessId()和GetCurrentThreadId()放在回调函数中）

Answer 1

Windows Mobile RIL 通常驻留在 device.exe（对于 WM6.x）中。但是，当您的流程调用 RIL 时，您的调用通过 RIL 代理传递。

RIL 代理与您的流程链接并驻留在您的流程中，并为您处理与流程边界相关的所有问题（顺便说一句，这至少是所有 RIL 数据结构需要打包到单个已知大小的内存块）。RIL 代理在内部创建一个线程，在该线程上执行您的回调。

这意味着您的代码可以使用 CRITICAL_SECTION 对象来提供必要的同步/保护。

Answer 2

使用互斥锁的关键在于您不知道哪个线程可能会进行回调。是的，关键部分也可以。小心，弄错会导致随机且很难诊断故障。

Answer 3

临界区是互斥体。关键部分与普通互斥锁（至少主要是）在一个方面不同：它特定于一个进程，其中互斥锁可以跨进程使用。

因此，在这种情况下，基本问题正是您要保护的内容——如果它是程序中的数据，其他进程无法访问，那么关键部分应该可以很好地完成这项工作。如果您要保护两个进程共享的东西，如果用户一次运​​行您的程序的两个实例，那么您可能需要一个互斥锁。

编辑：就必须使用关键部分来保护 RIL 本身所做的事情而言，不，不需要（或至少绝对不需要）。使用互斥锁，您指望所有进程通过打开具有相同名称的互斥锁来控制对共享资源的访问进行合作。您不能指望这一点，因此如果需要，界面会完全损坏。

更新：除非他们在 RIL 中做一些非常不寻常的事情，否则回调将在您的流程中发生，因此关键应该是足够的。如果它正在修改您的数据，则意味着您的数据已映射并对该代码可见——这意味着关键部分中的数据中的数据也将被映射和可见，并且它将起作用。关键部分不起作用的时间是当您处理单独的进程时，因此一个中的数据不会映射/对另一个不可见。

Answer 4

好吧，互斥锁和临界区（当然是 Windows 实现）之间的另一个区别是临界区是可重入的——即同一个线程可以两次获取临界区而不必释放它。