【问题标题】:Thread, abort and wait线程、中止和等待
【发布时间】:2013-08-05 17:04:10
【问题描述】:

我正在中止一个线程(很快就会成为线程),问题是我需要停止直到所有线程都被中止。

在完成Thread.Abort(); 之后,我想到了使用Thread.Join() 等到它完全中止。然而,这不起作用。它只是永远等待。如何中止每个线程并等到它完成后再继续?

附加信息:如果你好奇为什么——在这种情况下我正在关闭一个窗口,我将一个委托函数传递给它在完成(或中止)时调用的线程。如果我不停止,那么窗口将关闭并且该函数将调用无效句柄/objs。我可以轻松地使用相同的方法,插入一个标志并循环和睡眠,直到设置所有标志,但感觉不对。

【问题讨论】:

    标签: c# multithreading


    【解决方案1】:

    我从多年的线程经验中了解到,如果遵循这些规则,生活会变得轻松很多

    与这个问题相关的是:

    • 让线程控制它们自己的资源,包括它们的生命周期。

    我不会中止线程,我只是在线程创建者和线程本身之间建立一个通信方法来通知线程终止,然后让线程本身关闭。

    这种方法通常可以像控制线程主循环的创建者写入/线程读取标志一样简单。如果线程在循环中有长时间运行的任务,您还应该定期检查。

    然后创建者线程应该只是加入,直到线程退出。如果设计得当,您可以设置所需时间的上限。

    【讨论】:

      【解决方案2】:

      使用同步对象,例如事件。例如,每个后台线程都有一个与之关联的事件。当线程终止时,它会发出事件信号。主线程对事件集执行 WaitHandle.WaitAll,并且仅在所有事件都发出信号时才继续。

      请注意,如果后台线程有可能需要很长时间才能终止,则在等待主线程时阻塞主线程会造成糟糕的用户体验。因此,如果是这种情况,您可能希望在阻止之前隐藏窗口。此外,您还需要测试这对您的回调委托有什么影响——如果 UI 线程在等待中被阻塞,它是否能够处理您的委托?

      如果线程由于窗口关闭而被杀死,不调用委托不是更好的设计吗?只需让主线程告诉后台线程它们终止的原因,如果原因是“窗口关闭”,则让它们跳过回调。 (这假设您正在与线程通信,正如 Pax 正确建议的那样,而不是仅仅调用 Abort。)

      【讨论】:

        猜你喜欢
        • 2020-04-21
        • 2019-04-11
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 1970-01-01
        • 2011-02-04
        相关资源
        最近更新 更多