如何确保获取和设置操作的原子性以重定向 Console.Out 以记录控制台输出？

Question

我需要拦截控制台输出流，以便捕获它以记录日志，但仍将内容传递到原始流，以便应用程序正常工作。 这显然意味着在使用 Console.SetOut(new MyTextWriterClass(originalOut)) 更改之前存储原始的 Console.Out TextWriter。

我假设获取 Out 属性和调用 SetOut() 方法的各个操作是由 Console 以线程安全的方式实现的。 但我想确保其他一些线程（例如，运行我无法控制且无法期望更改的客户端应用程序代码，因此我不能依赖我自己的自定义锁定方案）不能在我的获取和设置之间意外地更改它，最终被我对它的更改覆盖（破坏了他们的应用程序的行为！）。 由于其他代码可能只是调用 SetOut()，因此我的代码理想情况下应该获得 Console 内部使用的相同锁（假设有一个）。

不幸的是，Console 是一个（静态）类，而不是实例，因此您不能只是锁定（Console）。 并且查看类文档似乎没有提到锁定。 这不是这些控制台方法的通常预期用法，但应该有一些安全的方法将其作为原子操作来执行。

如果标准锁定方案失败，是否有其他方法可以确保这一点？ 对于如此短的关键部分（并且仅执行一次），即使暂时阻塞所有其他线程也是可以接受的，如果这是唯一的方法的话。 我们使用 C# 和 .NET2.0。

如果甚至不可能（在不中断客户端应用程序的情况下），那么我们就只能依赖客户端应用程序不太可能重定向其控制台输出和 碰巧在 get 和 set 操作之间执行此操作。 我只是想涵盖所有基础，以防万一。

编辑：现在我们有了示例代码的具体答案，我已经重新措辞了问题标题，以更普遍地反映答案可以提供帮助的用例，从而更加清晰。 另外，添加了“原子”标签。

Answer 1

如果您查看 SetOut 的实现，它对我来说看起来是线程安全的：

[HostProtection(SecurityAction.LinkDemand, UI=true)]
public static void SetOut(TextWriter newOut)
{
    if (newOut == null)
    {
        throw new ArgumentNullException("newOut");
    }
    new SecurityPermission(SecurityPermissionFlag.UnmanagedCode).Demand();
    _wasOutRedirected = true;
    newOut = TextWriter.Synchronized(newOut);
    lock (InternalSyncObject)
    {
        _out = newOut;
    }
}

编辑

我能想到的最接近的解决方案是使用反射来获取其InternalSyncObject，然后锁定它。

需要注意的是，这是一个非常糟糕的主意，只有在没有其他选择的情况下才应该使用。 您可能会导致框架出现异常行为并使进程崩溃。

您还需要注意任何服务包和主要版本，以确保内部变量仍然被使用。 由于它是内部的，因此无法保证它会出现在下一个版本中。 如果您不是具有反射的对象，请编写您的代码并尝试很好地降低用户体验。

祝你好运：-）

Answer 2

好的，现在我有一些时间来实际实施 Josh 建议的反射方法。 基本代码（在我的 ConsoleIntercepter 类中，它继承自 TextWriter）是：

private static object GetConsoleLockObject()
{
    object lockObject;
    try
    {
        const BindingFlags bindingFlags = BindingFlags.GetProperty |
            BindingFlags.Static | BindingFlags.NonPublic | BindingFlags.Public;
        // It's currently private, but we'd be happy if it were public, too.
        Type consoleType = typeof(Console);

        lockObject = consoleType.InvokeMember("InternalSyncObject", bindingFlags,
                                              null, null, null);
    }
    catch
    {
        lockObject = null; // Return null on any failure.
    }
    return lockObject;
}
public static void RegisterConsoleIntercepter()
{
    object lockObject = GetConsoleLockObject();
    if (lockObject != null)
    {
        // Great!  We can make sure any other changes happen before we read
        // or after we've written, making this an atomic replacement operation.
        lock (lockObject)
        {
            DoIntercepterRegistration();
        }
    }
    else
    {
        // Couldn't get the lock object, but we still need to work, so
        // just do it without an outer lock, and keep your fingers crossed.
        DoIntercepterRegistration();
    }
}

类似于：

private static void DoIntercepterRegistration()
{
    Console.SetOut(new ConsoleIntercepter(Console.Out));
    Console.SetError(new ConsoleIntercepter(Console.Error));
}

然后 DoIntercepterRegistration()将 Out 和 Error 的受锁保护的原子替换； 显然，实际的拦截、处理和传递给前面的 TextWriter 需要额外的代码，但这不是这个问题的一部分。

请注意（在为.NET2.0提供的源代码中）Console类使用InternalSyncObject来保护Out和Error的初始化并保护SetOut()和SetError()，但它不使用Out和Error的读取周围的锁一旦它们之前被初始化。 这对于我的特定情况来说已经足够了，但如果你做了更复杂（和疯狂）的事情，可能会违反原子性； 我想不出任何有用的场景来解决这个问题，但可以想象故意病态的场景。

Answer 3

如果您可以在 Main() 中尽早执行此操作，那么您将有更好的机会避免任何竞争条件，特别是如果您可以在创建工作线程之前执行此操作。 或者在某个类的静态构造函数中。

如果 Main() 标记有 [STAThread] 属性，它将在单线程单元中运行，因此这也应该有所帮助。

Answer 4

一般来说，我会使用安全模型来防止客户端代码在您不注意时重定向控制台。 我确信这需要完全信任，因此如果客户端代码在部分信任的情况下运行，它将无法调用 SetOut()。