我已经阅读了这方面的文档，我想我明白了。AutoResetEvent当代码通过时，An会重置event.WaitOne()，但 aManualResetEvent不会。

它是否正确？

我正在寻找一种设计模式，以从使用 ManualResetEvent 切换到使用 Thread.Join 等线程方法。现在我正在进行异步调用，然后使用 ManualResetEvent 等待异步调用完成，然后再继续进行调用的线程。

我很高兴能够产生更稳定和易读的代码的任何实现。有兴趣查看使用 C# yield 关键字和 F# Async（如果有）的实现。

谢谢。

我使用msdn 上的这篇文章作为主要助手编写了我的代码

我的代码：

这就是发生的情况，我在 BeginAccept 处设置了一个断点（我认为有问题），但它正常执行。但是，当我尝试执行“_AllDone.WaitOne()”时 - 服务器崩溃。

如果 _allDone 不能在 win32 表单应用程序中使用 - 我如何制作我的项目？

编辑

我忘了提到我在Accept()中写了_AllDone.Reset()，但它没有去那里，我在那里设置了一个断点，但它不会去。

我实现了以下后台处理线程，其中Jobs是Queue<T>：

这在输入作业和实际开始运行之间产生了明显的延迟（一次输入批量作业，并且每个作业只是[相对]小。）延迟并不是什么大问题，但我开始思考这个问题，并进行了以下更改：

添加作业的线程现在在添加作业后锁定_workerWait并调用_workerWait.Set()。该解决方案（似乎）立即开始处理作业，并且延迟完全消失了。

我的问题部分是“为什么会发生这种情况？”，当然Thread.Sleep(int)可以睡得比您指定的更长，部分是“如何ManualResetEvent达到这种性能水平？”。

编辑：由于有人询问了排队项目的功能，这里是，以及目前的完整系统。

我对我正在使用的 ManualResetEvent 有点困惑，它似乎没有解除阻塞。有谁知道为什么会这样？

我遇到的情况是这样的。实际情况非常复杂，我没有设法隔离一段可以合理发布以重现问题的代码。

编辑
我已经更新了下面的代码示例。这是在许多不同的对话框中执行的，我注意到其中一个点击了 this.mre.WaitOne(); 然后会发生一个“服务器忙”对话框，我需要在其中按“切换到”或“重试”，这将允许我的代码逐步通过 WaitOne() 调用，一切都会正常工作。我不确定它的相关性，但显然它很重要。

这是
WinForms RichTextBox 的后续内容：如何在 TextChanged 上执行格式化？

我有一个带有 RichTextBox 的 Winforms 应用程序，该应用程序会自动突出显示该框的内容。因为大文档的格式化可能需要很长时间，10 秒或更长时间，所以我设置了一个 BackgroundWorker 来重新格式化 RichTextBox。它遍历文本并执行一系列操作：

在执行此操作时，UI 仍保持响应。

BackgroundWorker 从 TextChanged 事件中启动。像这样：

后台工作者方法如下所示：

但是，对 SelectionColor 的每次分配都会触发 TextChanged 事件：无限循环。

如何区分源自外部的文本更改和源自进行格式化的 BackgroundWorker 的文本更改？

如果我可以独立于文本格式更改检测文本内容更改，我也可以解决此问题。

我不确定要采用哪种策略...我专注于完成我的操作，但我也希望将性能问题控制在最低限度...有一个名为Execute()的方法必须等待（同步运行）直到操作完成。此操作发生在另一个线程上。有两种方法可以实现同一件事......

通过使用 ManualResetEvent

或者

通过使用简单的 while 构造

我应该采用两种方法中的哪一种……为什么？

编辑：

Q2。如果我只是在构建时有一个空的怎么办？有什么不同...？

编辑：（我之前收集的东西）

http://www.yoda.arachsys.com/csharp/threads/waithandles.shtml - 本文说手动重置相对较慢，因为它们退出托管代码并重新进入......

我觉得我应该知道这个问题的答案，但无论如何我都会问，以防万一我犯了一个潜在的灾难性错误。

以下代码按预期执行，没有错误/异常：

当然，与多线程代码的情况一样，成功的测试并不能证明这实际上是线程安全的。如果我放Closebefore Set，测试也会成功，即使文档明确指出尝试在 a 之后执行任何操作Close都会导致未定义的行为。

我的问题是，当我调用该ManualResetEvent.Set方法时，是否保证在将控制权返回给调用者之前向所有等待线程发出信号？换句话说，假设我能够保证不会再调用，在这里关闭句柄是否安全，或者在某些情况下，此代码可能会阻止某些服务员收到信号或导致一个？WaitOneObjectDisposedException

该文档仅说Set将其置于“信号状态”-它似乎没有声明服务员何时真正收到该信号，所以我想确定一下。

我目前正在创建一个服务器类型的应用程序，它将通常监听来自外部客户端的连接，并在它们连接时处理请求等。

目前，每次客户端连接时，我的实现都会创建一对线程。一个线程简单地从套接字读取请求并将它们添加到队列中，第二个线程从队列中读取请求并处理它们。

我基本上是在寻找关于你是否认为拥有所有这些线程是矫枉过正的意见，重要的是这种方法是否会给我带来问题。

需要注意的是，这些线程大部分时间都是空闲的——我在两个线程中都使用了等待句柄（ManualResetEvent）。Reader 线程一直等到消息可用，如果可用，则读取它并将其转储到 Process 线程的队列中。Process 线程一直等待，直到阅读器发出消息在队列中的信号（同样，使用等待句柄）。除非某个特定的客户端真的在敲击服务器，否则这些线程将一直处于等待状态。这很昂贵吗？

我做了一些测试 - 有 1,000 个客户端连接不断唠叨 - 服务器（所以，2,000 多个线程），它似乎处理得很好。

考虑一个控制台应用程序，它在单独的线程中启动一些服务。它需要做的就是等待用户按 Ctrl+C 将其关闭。

以下哪项是更好的方法？

或者这个，使用 Thread.Sleep(1)：