异步过程调用是否被另一个线程中断?

Ste*_*ock 1 c++ multithreading apc

我刚刚意识到我的APC被另一个线程打断了.所以在这一点上我想知道这是怎么回事.据我了解APC的概念:

  • APC不能被正常的用户模式线程中断
  • QueueUserAPC()请求后立即调度APC
  • APC具有运行到完成语义

所以这是我最初的情况:我有一个多线程应用程序(1个主线程,1个接收线程).较低优先级的接收线程是从外部源接收数据.接收线程也通过使用重新激活WaitForSingleObject().接收的数据存储在共享中std::list.主线程实际上没有任何效果.每隔x毫秒发生一次特殊事件,导致接收线程调度APC.此APC在主线程的上下文中运行.

所以这里是整个情况的示例伪源代码.

class Example {

public:
  Example(void) {
    ::DuplicatHandle(
        ::GetCurrentProcess(),
        ::GetCurrentThread(),
        ::GetCurrentProcess(),
        &m_mainthreadHandle,
        THREAD_SET_CONTEXT,
        FALSE,
        0);
  }

  void run(void) {
    ::WaitForSingleObjectEx(m_apcActivation);
  }

protected:

private:
  void rxThread(void) {
    // this seems to be called during the apcRoutine() is running
    // as result the shared list m_rxList is corrupted!
    ::WaitForSingleObject(m_externalActivation);

    Data data = externalReceive();

    if(data.attribute == SPECIAL) {
      ::QueueUserAPC(apcRoutine, m_mainthreadHandle, 0);
    } else {
      m_rxList.push_front(data);
    }
  }

  void apcRoutine(void) {
    while(!m_rxList.empty()) {
      m_rxList.front().print();
      m_rxList.pop_front();
    }
  }


  std::list<Data> m_rxList;
  HANDLE          m_externalActivation;
  HANDLE          m_apcActivation;
  HANDLE          m_mainthreadHandle;

};


void main(void) {

  Example e;

  e.run();

}
Run Code Online (Sandbox Code Playgroud)

我的问题是:WaitForSingleObject()接收线程是否有可能中断APC?如果是,为什么?

Dam*_*mon 5

你似乎对APC有一些误解.

有两种(实际上是三种)APC,用户模式和内核模式(具有两个不同的优先级)APC.

Usermode APC(例如您在代码中使用的APC)的行为与kernelmode APC的行为方式不同.特别是:

  • 他们不抢占线程,
  • 它们不会在您调用时立即运行,QueueUserAPC除非目标线程已在可警告的等待中被阻止.相反,APC 排队.
  • 否则它们仅在线程进入可警告等待或被NtTestAlert调用时运行.
  • 它们并非不可抢占,事实上它们本身并没有"特殊".它们只是回调,您可以排队到一个线程,并在明确定义的时间调用.
  • 它们不保证运行完成1,但它们保证按顺序执行.
  • 无法强制另一个线程执行其排队的APC.目标线程必须使其自身可以警告其APC运行.虽然存在无证件的功能NtAlertThread,但它并不像人们期望的那样工作,也不会NtAlertResumeThread.

另一方面,Kernelmode APC会抢占用户模式线程并且不会被它们中断(并且APC_LEVEL APC也不能被PASSIVE_LEVEL APC中断).


1如果情况确实如此,那将是非常荒谬的.这样,您可以使用APC完全破坏调度程序,消耗不确定的CPU时间 - 无论进程优先级,权限或配额如何.