What is the difference between SynchronizationContext.Send and SynchronizationContext.Post?

Question

Thanks to Jeremy Miller's good work in Functional Programming For Everyday .NET Development, I have a working command executor that does everything I want it to (do heavy lifting on the thread pool, send results or errors back to the synchronization context, and even post progress back to the synchronization context), but I can't explain why it uses SynchronizationContext.Send from the thread-pool and Synchronization.Post from the Func passed into the method that does the heavy lifting. I have read the documentation, several times, but I just can't get a gut sense for what the difference is. What am I supposed to get from the fact that one is called Send and one is called Post? I sense the magic is in the fact Send "starts a synchronous request" and Post "starts an asynchronous request", but both requests come from the thread pool and need to be sent/posted back to the UI thread.

Can someone explain the difference, even if it is just a mnemonic device that lets me know when to choose one over the other?

In case it matters, this is my test code where I use Post to send progress back to the UI:

private Action _ExecuteCommand
                (SynchronizationContext context
                 , Action<int, int> progress
                 , Action<int, int> after)
{
    int count = 3;
    int accumulatedValue = 0;
    int threadId = Thread.CurrentThread.ManagedThreadId;
    for (int i = 0; i < count; i++)
    {
        Thread.Sleep(1000);
        context.Post(delegate { progress(i + 1, threadId); });
        accumulatedValue += i;
    }

    return () => after(threadId, accumulatedValue);
}

That _ExecuteCommand method is passed in as the command parameter below, mostly from the original article, that uses Send to send completion and error message back to the UI:

public void Execute(Func<Action> command, Action<Exception> error)
{
    ThreadPool.QueueUserWorkItem(o =>
     {
         try
         {
             Action continuation = command();
             _Context.Send(s => continuation());
         }
         catch (Exception e)
         {
             _Context.Send(s => error(e));
         }
     });
}

Bachelorism

They are really badly named methods. – Mcwhorter

Answer 1

Send - synchronous: wait for answer (or action completed)

Post - asynchronous: drop off and continue

So your example uses the correct methods at the right moments. There is no need to halt the for-loop until the progress update is complete (on the contrary).
And Execute does want to wait for the Action to complete, otherwise the exception handling has no purpose.

Portraiture

So no errors result if I use Post instead of Send. It is just about whether I need the thread pool task to pause for the message to be sent/posted. Right? – Bachelorism

I'm still confused by this. I thought the synchronization context gave you an easy way to do some work on the UI thread, so would you not have to wait for it? Or does it work like this: You're doing some work on a background thread and in the middle you need to do some UI work and then continue in background thread. If you use Send the background thread doesn't continue to part 2 until UI work finishes, however if you use Post the background thread will continue to work without waiting on the UI thread work? – Applejack

Easy to remember: You don't wait the Post, you only hopes that it will deliver your message. – Lentil

@TheMuffinMan The naming may seem silly or confusing, but that is because it is based on a lower level abstraction. Most people consuming SynchronizationContext only care about invoking a method synchronously or asynchronously--doing work as you put it; however, at a slightly lower level this is handled via messages and message processing. At that level, the naming mostly makes sense, though Send and SendAsync might have been better. That said, considering how and when it is used, Invoke and InvokeAsync might have been more straightforward. – Tactician

Post, Send – Indebtedness