c# - Slim 同步类是按 AppDomain 还是按进程？

Question

Internet 上所有文章都说使用Thread.Abort 是邪恶的(因为同步原语属于操作系统，进程还没有终止，线程中止后原语可能保持锁定状态)。开发人员建议终止整个进程，因为操作系统将在进程停止时释放同步原语。

1. AppDomain 卸载有帮助吗，如果使用 Slim 同步原语？ (在 .net 4.0 中添加了几个与线程相关的新类:ManualResetEventSlim、SemaphoreSlim、ReaderWriterLockSlim)。

   文档说这些原语不能在不同进程之间使用，因为原语的实现代码是完全托管的。但我不明白 - 这些原语是否会通过 AppDomain 边界工作。 (参见 Can't set synchronization context when using appdomains)

2. 如果是，他们是怎么做到的？如果不是，那么为什么文档忽略了这个限制？

更新:我信任我的所有代码，包括我卸载的域内的代码。我不想在终止线程时让线程继续工作。我想终止(中止)线程而不是“设置标志”和“制作漂亮的架构”。如果有必要首先创建额外的线程(我认为这在单独域中的后台处理开始时有必要创建一个线程)，我会这样做。我不想使用“设置标志”方法，因为它需要我用标志检查来检测后台算法，我不应该，它是运行时或编译器应该为我自动检测。目前还没有这样的工具，这就是为什么我尝试将该方法应用于域卸载。

在每条指令之间(或在深层嵌套循环中)添加检查会显着降低代码速度。在随机位置添加检查不会保证及时终止。如果可以解决编写中止安全代码的困难，为什么不尝试中止线程和卸载域？

Answer 1

您误解了 AppDomain、Process 和 Thread 定义 - AppDomains always lives in one process, but one process can be a master for different AppDomains *:

The ability to run multiple applications within a single process dramatically increases server scalability.

• 这与 Thread 类似，仅供引用。

因此，您的问题的答案是是，slim synchronization primitives将与各种AppDomains一起工作，因为在这种架构中没有跨进程调用，只是对各种进程进行逻辑区分。

至于链接的问题，同步原语没有问题，只有 SynchronizationContext 是 Thread-specific，但是不是 AppDomain 特定的。

您可以在这里找到有关 AppDomain、Thread 和 Process 之间区别的很好的答案:Difference between AppDomain, Assembly, Process, and a Thread

至于卸载 AppDomain，我认为你可以重构你的代码，因为你可以在你的 AppDomain 中启动一个 worker Thread 来限制对系统资源的访问，然后只需等待它完成，例如 it mentioned here :

using System;
using System.Threading;
using System.Threading.Tasks;

class Program
{
    static void Main()
    {
        var ad = AppDomain.CreateDomain("WhereTheWorkHappens");

        Task<string> t = DoWorkInOtherDomain(ad);
        Console.WriteLine("waiting...");
        Console.WriteLine(t.Result);

        Console.ReadLine();
    }

    static Task<string> DoWorkInOtherDomain(AppDomain ad)
    {
        var ch = new MarshaledResultSetter<string>();

        Worker worker = (Worker)ad.CreateInstanceAndUnwrap(typeof(Worker).Assembly.FullName, typeof(Worker).FullName);
        worker.DoWork(ch);

        return ch.Task;
    }

    class Worker : MarshalByRefObject
    {
        public void DoWork(MarshaledResultSetter<string> callback)
        {
            ThreadPool.QueueUserWorkItem(delegate
            {
                Thread.SpinWait(500000000);
                callback.SetResult(AppDomain.CurrentDomain.FriendlyName);
            });
        }
    }

    class MarshaledResultSetter<T> : MarshalByRefObject
    {
        private TaskCompletionSource<T> m_tcs = new TaskCompletionSource<T>();
        public void SetResult(T result) { m_tcs.SetResult(result); }
        public Task<T> Task { get { return m_tcs.Task; } }
    }
}

作为您的额外想法，您可以阅读有关 Sandboxing your code with TPL 的内容，我认为这是更好的方法，因为您无需手动管理系统资源，并且被不受信任的代码攻击的可能性较小。

此外，您还可以使用 Cross-AppDomain Marshaling friendly TPL wrappers for APM 找到一个 GitHub 项目