【问题标题】:Named Pipe Problem命名管道问题
【发布时间】:2009-10-13 22:16:06
【问题描述】:

是否有一个函数,当另一端成功调用管道上的ReadFile时返回。 我有 2 个应用程序在命名管道上进行通信,一个使用 WriteFile 在管道上发送请求并期望得到答案,因此它调用 ReadFile。问题是应用程序正在读取自己的请求作为答案,因为另一端尚未将其从管道中删除。

有这样的功能吗?

我知道另一种方法是使用 2 个单向管道或通过让其他应用程序在收到消息时向发送者发出信号来实现某种或同步,但我只是在检查是否有更简单的方法...

【问题讨论】:

    标签: windows winapi named-pipes


    【解决方案1】:

    我认为您正在寻找的方法是PeekNamedPipe。此功能将允许您在不删除数据的情况下查看管道。您可以使用它来检查您刚刚发送的消息是否仍在管道中。如果是,那么另一端还没有读到消息。

    不过,总的来说,我认为您最好使用一个信号或两个单向管道。它们更适合双向通信。

    【讨论】:

    • 我会警告不要在这里使用 PeekNamedPipe()。当您的程序从 PeekNamedPipe() 返回时,如果两个进程同时在管道上读取/写入,这将成为问题并且容易出现竞争,因为您将永远无法依赖它返回的值在您得到时仍然存在到您的 ReadFile() 调用。
    • @asveikau,完全同意。这就是我推荐信号或 2 个管道的原因。单个管道本质上是有保证的竞争条件
    • 还有,怎么说其他应用程序没有读取你在管道上发布的数据,只是直接写回来,现在正在等你......
    【解决方案2】:

    您的设计天生就容易出现竞争条件,我强烈建议您改用两个管道。特别是,您是否考虑过当两个进程想要写入同一个管道时会发生什么?

    也就是说...您可以使用event 进行同步。完成 WriteFile() 后,您可以wait 通知事件。当另一端用 ReadFile() 完成后,它可以SetEvent()。这可能会奏效,前提是两端具有明确定义的合同并且不会相互竞争或相互僵持。

    【讨论】:

      猜你喜欢
      • 2016-03-30
      • 2010-12-18
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2014-03-31
      • 1970-01-01
      • 2011-03-27
      相关资源
      最近更新 更多