call method from another thread without blocking the thread (or write custom SynchronizationContext for non-UI thread) C#

Question

This is probably one of the most frequent questions in the Stackoverflow, however I couldn't find the exact answer to my question: I would like to design a pattern, which allows to start thread B from thread A and under specific condition (for example when exception occurs) call the method in thread A. In case of exception the correct thread matters a lot because the exception must call a catch method in the main thread A. If a thread A is an UI thread then everything is simple (call .Invoke() or .BeginInvoke() and that's it). The UI thread has some mechanism how it is done and I would like to get some insights how it would be possible to write my own mechanism for the non-UI thread. The commonly suggested method to achieve this is using the message pumping
http://www.codeproject.com/Articles/32113/Understanding-SynchronizationContext-Part-II
but the while loop would block the thread A and this is not what I need and not the way how UI thread handles this issue. There are multiple ways to work around this issue but I would like to get a deeper understanding of the issue and write my own generic utility independently of the chosen methods like using System.Threading.Thread or System.Threading.Tasks.Task or BackgroundWorker or anything else and independently if there is a UI thread or not (e.g. Console application).

Below is the example code, which I try to use for testing the catching of the exception (which clearly indicates the wrong thread an exception is thrown to). I will use it as an utility with all the locking features, checking if a thread is running, etc. that is why I create an instance of a class.

class Program
{
    static void Main(string[] args)
    {
        CustomThreads t = new CustomThreads();
        try
        {
            // finally is called after the first action
            t.RunCustomTask(ForceException, ThrowException); // Runs the ForceException and in a catch calls the ThrowException
            // finally is never reached due to the unhandled Exception
            t.RunCustomThread(ForceException, ThrowException);
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
        // well, this is a lie but it is just an indication that thread B was called
        Console.WriteLine("DONE, press any key");
        Console.ReadKey();
    }

    private static void ThrowException(Exception ex)
    {
        throw new Exception(ex.Message, ex);
    }

    static void ForceException()
    {
        throw new Exception("Exception thrown");
    }
}

public class CustomThreads
{
    public void RunCustomTask(Action action, Action<Exception> action_on_exception)
    {
        Task.Factory.StartNew(() => PerformAction(action, action_on_exception));
    }

    public void RunCustomThread(Action action, Action<Exception> action_on_exception)
    {
        new Thread(() => PerformAction(action, action_on_exception)).Start();
    }

    private void PerformAction(Action action, Action<Exception> action_on_exception)
    {
        try
        {
            action();
        }
        catch (Exception ex)
        {
            action_on_exception.Invoke(ex);
        }
        finally
        {
            Console.WriteLine("Finally is called");
        }
    }
}

One more interesting feature that I've found is that new Thread() throws unhandled Exception and finally is never called whereas new Task() does not, and finally is called. Maybe someone could comment on the reason of this difference.

Answer 1

and not the way how UI thread handles this issue

That is not accurate, it is exactly how a UI thread handles it. The message loop is the general solution to the producer-consumer problem. Where in a typical Windows program, the operating system as well as other processes produce messages and the one-and-only UI thread consumes.

This pattern is required to deal with code that is fundamentally thread-unsafe. And there always is a lot of unsafe code around, the more convoluted it gets the lower the odds that it can be made thread-safe. Something you can see in .NET, there are very few classes that are thread-safe by design. Something as simple is a List<> is not thread-safe and it up to you to use the lock keyword to keep it safe. GUI code is drastically non-safe and no amount of locking is going to make it safe.

Not just because it is hard to figure out where to put the lock statement, there is a bunch of code involved that you did not write. Like message hooks, UI automation, programs that put objects on the clipboard that you paste, drag and drop, shell extensions that run when you use a shell dialog like OpenFileDialog. All of that code is thread-unsafe, primarily because its author did not have to make it thread-safe. If you trip a threading bug in such code then you do not have a phone number to call and a completely unsolvable problem.

Making a method call run on a specific thread requires this kind of help. It is not possible to arbitrarily interrupt the thread from whatever it is doing and force it to call a method. That causes horrible and completely undebuggable re-entrancy problems. Like the kind of problems caused by DoEvents(), but multiplied by a thousand. When code enters the dispatcher loop then it is implicitly "idle" and not busy executing its own code. So can take an execution request from the message queue. This can still go wrong, you'll shoot your leg off when you pump when you are not idle. Which is why DoEvents() is so dangerous.

So no shortcuts here, you really do need to deal with that while() loop. That it is possible to do so is something you have pretty solid proof for, the UI thread does it pretty well. Consider creating your own.