c# - Console.SetError 是线程安全的吗？

Question

在有多个线程调用 Console.Write 的正在运行的程序中，我可以调用 Console.SetError 来设置新流吗？ IE。这是线程安全的吗？

背景: 我有一个程序可以不间断地运行几天，它会将大量日志输出到文件中，并且我希望每天都有一个单独的日志文件，这样我就可以偶尔删除最旧的文件。我认为，最简单的方法是，只需以分钟为间隔检查一天是否已经过去，如果是，则创建一个新文件并将流分配给错误输出。我尝试在系统处于非事件状态一段时间但没有其他花哨的检查时执行此操作，因此当交换发生时，它可能正在写入(旧)流。 (我不在乎输出线是否被分成两半，但会介意崩溃，呵呵)

MSDN提到Console的“I/O操作是线程安全的”，但在我的书中对SetError的调用不是IO操作，并且SetError的MSDN页面没有提到这一点。

Answer 1

大概在你的程序中，你会在不同的地方做类似这样的事情:

catch (Exception e)
{
    Console.Error.WriteLine(e);
}

Talking about whether something is thread safe isn't really meaningful because it means radically different things to different people and in different contexts.

只讨论代码中可能发生和不可能发生的事情会更有效。

• 传递给 Console.Error.WriteLine 的字符串将被写入 some 流。没有办法让错误消息“掉在地上”而不被写入任何地方。

• 传递给 WriteLine 调用的字符串不会部分写入一个流，部分写入另一个流。整个字符串将被写入 some 流，只是如果该调用与 SetError 调用大约在同一时间，我们不一定知道是哪个流。这是因为 Console.Error 首先被评估为一个引用，然后该引用被告知写出一个字符串。将变量 Console.Error 更改为引用另一个对象不会影响您已经引用的编写器。

• 字符串在更改后可能会写入“旧”流。当调用者已将 Console.Error 计算为该变量的值(对文本编写器的引用)但尚未实际写入时，就会发生这种情况。

• 代码也完全有可能获取对 Console.Error 的引用，保留它，然后继续写入。如果这种情况发生在您的应用程序中，而不是每次需要错误流时都不断地评估 Console.Error ，那么旧文件可能会继续使用，可能在您调用 SetError 之后很长时间 并更改了错误流。

• 多次调用 Console.Error.WriteLine 可能会出现在多个文件中。如果消息不跨越多个文件很重要，则不需要多次评估 Console.Error。