ios - 将 InvokeOnMainThread 嵌套在锁内，反之亦然

将其中一个嵌套在另一个中是否不好？过去，我有一个挂起/死锁问题，在执行顶部代码块时我可以重现，而当我将其更改为底部代码块时我无法重现......我真的不明白时间，我仍然没有。关于 Lock 和 InvokeOnMainThread 的组合有什么我应该知道的吗？我可以提供更多关于我在做什么的细节，但这更像是一个普遍的问题......

假设我想在后台线程中“DoStuff”。我有一个可以从多个线程访问的变量。

lock( stuff )
{
    InvokeOnMainThread ( delegate {
        stuff.DoStuff();
    });
}

替代

InvokeOnMainThread ( delegate {
    lock( stuff )
    {
        stuff.DoStuff();
    }
});

添加信息:我有一个带有连接管理器功能的 iOS 应用程序，该功能在后台线程中运行。连接管理器功能负责保持事件和管理异步网络套接字连接。在很多情况下，我需要在执行操作时调用 InvokeOnMainThread，否则我会收到以下错误“UIKit 一致性错误:您正在调用只能从 UI 线程调用的 UIKit 方法。”

---

Best Answer-推荐答案

两者之间的区别在于，第二个代码块不会阻止在执行 DoStuff 之前在执行线程上执行任何操作。

例子:

 lock (stuff) {
     InvokeOnMainThread ( delegate { Console.WriteLine ("a"); } }
 }
 Console.WriteLine ("b");

将打印:

a
b

这段代码:

 InvokeOnMainThread ( delegate {
    lock (stuff) {
        Console.WriteLine ("a");
    }
 }
 Console.WriteLine ("b");

通常(但不一定)会打印:

b
a

现在这并不能解释为什么第二个 block 会修复竞态条件，但我的猜测是它只会改变竞态条件，足以让你不再击中它(所以不要修复它，只是隐藏它) .

关于ios - 将 InvokeOnMainThread 嵌套在锁内，反之亦然，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/22768212/