使用 TThread.Resume 有什么问题？ [复制]

Question

很久以前，当我开始在 Delphi 中使用线程时，我通过在构造函数末尾调用 TThread.Resume 来让线程自己启动，现在仍然这样做：

constructor TMyThread.Create(const ASomeParam: String);
begin
  inherited Create(True);
  try
    FSomeParam:= ASomeParam;
    //Initialize some stuff here...
  finally
    Resume;
  end;
end;

从那时起，Resume 已被弃用，取而代之的是使用 Start。但是Start只能从线程外调用，不能从构造函数内调用。

我继续使用Resume 设计我的线程，如上所示，虽然我知道它已被弃用 - 只是因为我不想从线程外部调用Start。我觉得不得不打电话有点乱：

FMyThread := TMyThread.Create(SomeParamValue);
FMyThread.Start;

问题：进行此更改的原因是什么？我的意思是，使用 Resume 有什么问题，以至于他们希望我们改用 Start？

编辑 在 Sedat 的回答之后，我想这真的取决于在构造函数中线程何时真正开始执行。

Answer 1

简短而精辟的答案是因为 TThread 类的作者不相信开发人员会阅读或理解文档。 :)

暂停和恢复线程是仅对非常有限数量的用例的合法操作。事实上，这个有限的数字本质上是“一个”：Debuggers

不受欢迎的

它被认为是不可取的（至少可以说）的原因是，如果一个线程被挂起，而（例如）它拥有某个其他同步对象（例如互斥体或信号量等）上的锁，则会出现问题。

这些同步对象专门设计用于确保一个线程相对于其他线程访问共享资源的安全操作，因此中断和干扰这些机制可能会导致问题。

调试器需要一个工具来直接挂起一个线程，而不管这些机制如何，原因惊人地相似。

例如，假设断点涉及线程上的隐式（或者您甚至可以说 explicit）“挂起”操作。如果调试器在到达断点时暂停线程，那么它还必须暂停进程中的所有其他线程，因为否则它们将抢先执行可能会干扰调试器可能被要求执行的许多低级任务的工作那就去做吧。

调试器的强大武器

调试器不能“注入”漂亮的、礼貌的同步对象和机制来请求这些其他线程以协调的方式挂起自己，与其他一些已经被随意停止（通过断点）的线程协调。调试器别无选择，只能对线程进行强力武装，而这正是 Suspend/Resume API 的用途。

它们适用于需要停止线程“现在。无论你在做什么我不在乎，停下来！”的情况。然后，然后说“好的，你现在可以继续你以前在做什么，不管它是什么。”。

表现良好的线程彼此之间表现良好

很明显，这不是一个表现良好的线程在正常操作中如何与其他线程交互（如果它希望保持“正常”操作的状态而不是创建各种的问题）。在这些正常情况下，一个线程非常确实并且应该关心那些其他线程正在做什么并确保它不会干扰，使用适当的同步技术来协调那些其他线程。

在这些情况下，恢复线程的合法用例同样被简化为一种单一模式。也就是说，您创建并初始化了一个线程，您不希望立即运行该线程，而是希望在稍后某个时间点在其他线程的控制下开始执行。

但是一旦新线程启动，随后与其他线程的同步必须使用那些适当的同步技术来实现，不是蛮力暂停它的力量。

开始与暂停/恢复

因此决定 Suspend/Resume 在通用线程类中没有真正的位置（实现调试器的人仍然可以直接调用 Windows API），取而代之的是提供了更合适的“开始”机制。

希望很明显，即使此 Start 机制使用与之前已弃用的 Resume 方法完全相同的 API，但目的却大不相同。