Question

A colleague of mine found an issue with our code and it took a while to hunt down exactly what was happening, but it can be best demonstrated by this simple example:

// Fails
class Program
{
    static void Main(string[] args)
    {
        Task.Run(() => Console.WriteLine("Hello World"));
        Console.ReadKey();
    }
}

// Works fine
class Program
{
    static void Main(string[] args)
    {
        Console.Write(String.Empty);
        Task.Run(() => Console.WriteLine("Hello World"));
        Console.ReadKey();
    }
}

It’s clear from playing around with this that writing to the console anywhere from the main thread will allow the background thread to write to the console also, but we are struggling to understand why this is happening. Can anyone explain what writing to the console from the main thread achieves that the first snippet does not?

Answer 1

I have a suspicion as to what’s going on. What I’ve observed:

• If you do anything with the console’s output before starting the ReadKey, it’s fine. This includes fetching Console.Out but not using it
• If you put a delay in so that the Console.WriteLine call starts before the Console.ReadKey call, it’s fine (and you can have multiple WriteLine calls while ReadKey is waiting

I suspect that the first operation to use the console acquires a lock for initialization (to avoid it being initialized twice) and that the ReadKey method keeps hold of the lock until a key has been read. That would certainly explain every program I’ve run so far.

The operations which perform the hypothesized initialization are interesting though – reading Console.Out “fixes” the issue, but reading from Console.In doesn’t.

I suspect that ReadKey initializes the output because the value is still echoed to the console… but I wouldn’t like to swear to it.

Interestingly, using Console.ReadLine() instead of Console.ReadKey() doesn’t cause the problem in the first place.