Is it possible to build thread context/safety into UI controls—Invoke/BeginInvoke/Dispatch.Post/Send, etc. to remove boilerplate and so that we don't need to worry about SynchronizationContext(s)?

[Shidell]

Overview

A lot of effort is spent marshalling UI control updates to the UI thread. I am wondering (proposing?) that the Control base class is modified to handle these details internally, automatically—but leaves existing functionality (Invoke and BeginInvoke) in place. (So, hypothetically, a non-breaking change.)

I would like to continue the discussion that was started here: #4631

Proposal

Controls are already aware of their UI thread (and expose it via InvokeRequired) and have a built-in means of searching for it as part of Invoke and BeginInvoke. I'm proposing that instead of WinForms developers writing something like this:

if (Control.InvokeRequired) Control.BeginInvoke(new MethodInvoker(() => { Control.Text = "Update"; } ));

That they could instead just mutate the Property as they would normally (on the UI thread):

Control.Text = "Update";

I am not proposing any changes to InvokeRequired/Invoke/BeginInvoke. I think they all have a purpose, and being able to execute a Delegate (or an Action directly, as proposed in #4608) makes sense.

Why?

There is a lot of confusion around this subject, I tried to expound some of them in the discussion in #4631.

If what I'm proposing is feasible, then I think it would greatly simplify mutating a UI Control. Developers can access a Control's Property normally (Control.Text = "Update";) and those changes are automatically handled by the framework.

In situations where a developer attempts to update a UI Control improperly right now (DoWork of a BackgroundWorker, or within a Thread or Task on the Threadpool, or inside of an awaited asynchronous method), this proposal would safely handle those mutations for them. (Whether or not their code is following best practice guidelines is another story.) Regardless, I think this change would improve safety and stability.

Further, there are a number of .NET constructs and recommendations that are predicated on marshalling UI Controls to update on the UI thread—and I think this proposal could eliminate the need for some of these.

• SynchronizationContext could potentially be eliminated (unless it has other duties I'm not currently familiar with)
• (The same goes for the Dispatcher (in WPF))
• Async/Await no longer needs to capture UI context and restore it
• Approaches like await uiThreadTaskScheduler.SwitchTo() and TaskScheduler.Default.SwitchTo() would no longer be necessary

This proposal also solves for the cases when best practices aren't possible (for whatever reason). For example, the best practice is to always update the UI from the UI thread:

DoWorkAsync()
{
    Thread.Sleep(1000); // Simulating work
}

await DoWorkAsync();
Control.Text = "Update";

But when that isn't possible, and something like this occurs, it wouldn't be an issue:

DoWorkAsync()
{
    Thread.Sleep(1000); // Simulating work
   
    Control.Text = "Update";
}

I think it's particularly beneficial inside of an async method, because there is no guarantee that the State Machine is running on the Threadpool, and it could be running on the UI thread—so code written like the above example may execute just fine on the developer's computer repeatedly, only to fail later on.

Is this proposal logical, feasible, technically correct?

I feel like what I'm suggesting is too common-sense to not have been implemented a long time ago, and so I doubt the veracity of my claims.

If this proposal makes sense, I'm willing to work on it.

[weltkante]

SynchronizationContext could potentially be eliminated (unless it has other duties I'm not currently familiar with)

You cannot eliminate that, it is the framework-independent API for doing thread switches, in e.g. libraries which aren't tied to WinForms only but can be used in any context. In fact much of the .NET runtime makes use of SynchronizationContext in this framework independent manner, in particular it is why when you await something you will continue on the right thread and don't have to worry about thread switches happening behind your back.

I feel like what I'm suggesting is too common-sense to not have been implemented a long time ago, and so I doubt the veracity of my claims.

While this proposal tries to solve one problem, I have concerns with new problems being introduced:

• For performance aware programming you still have to do manual thread switches anyways. Doing thread switches automatically on every method call instead of doing it once in the caller has a negative impact on performance if you didn't do that manual thread switch you have to do today.
• It does lots of unnecessary waiting in order to report results/exceptions to the caller. It has to use synchronous Invoke instead of "fire and forget" BeginInvoke which often could be used in the caller because an event handler has no result to report.
• Each thread switch carries risk for deadlocks, doing it automatically significantly increases the risk of deadlocks. An exception is something that can be reported, deadlocks do not generate stack traces and have no easy means to report from end user to developer.

Threading is hard, this proposal will remove one case of complexity (manually switching threads) by trading it off for a different complexity (deadlocks become more common).

I'm not entirely opposed but I personally don't feel the "it just works" experience is worth the decrease in quality. The current clear exception meant bugs usually got fixed, deadlocks have no stack trace and will need to be reproduced, meaning less deadlocks will actually get fixed, resulting in decreased quality of WinForms applications. Also the hidden performance degredation you get when you use this feature means you have to spend more time optimizing your call sites, by replicating what you currently have to do anyways, switching the thread manually.

Personally I prefer the current behavior, the exception is deterministic (even if its only in debug builds) and has a documented solution.

[Shidell]

Thanks for considering what I proposed. I've been looking at the WinForms source code and trying to better understand what it does (and why) in context of what I was suggesting, and I'm also trying to understand your points and take them to heart.

I wanted to follow-up on the points you offered:

• It does lots of unnecessary waiting in order to report results/exceptions to the caller. It has to use synchronous Invoke instead of "fire and forget" BeginInvoke which often could be used in the caller because an event handler has no result to report.

• Each thread switch carries risk for deadlocks, doing it automatically significantly increases the risk of deadlocks. An exception is something that can be reported, deadlocks do not generate stack traces and have no easy means to report from end user to developer.

Are you referring to using SendMessage? What I was hoping to express in my Proposal would be replacing SendMessage calls in Control (and objects that inherit from it) and replacing it with PostMessage, which I believe would remove the risk for deadlock altogether? (And I don't believe PostMessage causes a thread context switch, but I'm not certain, I'm still investigating.)

I'd like to present a new example, now that I'm actually looking at the internals of some WinForms code. For example, here's an excerpt from RadioButton's Checked method, simply replacing SendMessage with PostMessage:

public bool Checked
{
    get
    {
        return isChecked;
    }

    set
    {
        if (isChecked != value)
        {
            isChecked = value;

            if (IsHandleCreated)
            {
                //User32.SendMessageW(this, (User32.WM)User32.BM.SETCHECK, PARAM.FromBool(value));
                User32.PostMessageW(this, (User32.WM)User32.BM.SETCHECK, PARAM.FromBool(value));
            }

            Invalidate();
            Update();
            PerformAutoUpdates(false);
            OnCheckedChanged(EventArgs.Empty);
        }
    }
}

Another example, ProgressBar's Minimum Property:

public int Minimum
{
    get => _minimum;
    set
    {
        if (_minimum != value)
        {
            // Ensure that value is in the Win32 control's acceptable range
            if (value < 0)
            {
                throw new ArgumentOutOfRangeException(nameof(value), value, string.Format(SR.InvalidLowBoundArgumentEx, nameof(Minimum), value, 0));
            }

            if (_maximum < value)
            {
                _maximum = value;
            }

            _minimum = value;

            if (_value < _minimum)
            {
                _value = _minimum;
            }

            if (IsHandleCreated)
            {
                //User32.SendMessageW(this, (User32.WM)ComCtl32.PBM.SETRANGE32, (IntPtr)_minimum, (IntPtr)_maximum);
                User32.PostMessageW(this, (User32.WM)ComCtl32.PBM.SETRANGE32, (IntPtr)_minimum, (IntPtr)_maximum);
                UpdatePos();
            }
        }
    }
}

This should preserve thread safety, because adding a message to the message queue isn't blocking, and so I don't believe there's any (additional) risk of deadlock here—is there? (I might be too ignorant to fully understand.)

Some additional thoughts and concerns I have about this suggestion:

• What's the real-time performance impact of using PostMessage instead? I'm trying to account for a developer's need for their message to be handled immediately (SendMessage) vs. allowing the message pump to dispatch it "in-order" (PostMessage.) It feels like there might be potential performance issues in performance-sensitive applications, but on the other hand, PostMessage should guarantee thread safety, and I think executing messages in-order makes more sense. For example, if I've queued updates to a Progress Bar in the message queue, but then I send an update immediately via SendMessage, the updates in the queue might no longer be relevant and/or cause a problem because they're no longer valid in the context of whatever the SendMessage was.

• I considered what would happen if the message queue overran it's maximum (which I believe is 4,000 messages, up to 10,000 with a registry edit), but decided that a message queue with 4,000 items in it is already poorly designed and there's no way the UI will keep up with the messages anyway, so it's not really a concern?

• I ran the tests for CheckBox and ProgressBar, and all passed in 2.7s on my machine, using both SendMessage and PostMessage. That might not mean much, but I thought it worth trying (and noting.)

• If PostMessage does not cause a thread context switch, and guarantees thread safety, and is sufficient for even performance-critical systems, wouldn't that be a better default choice then SendMessage?

• Assuming the above is true, then Controls using PostMessage would be safe to use from any thread, allowing the developer to mutate them as they would from the UI thread safely—and there wouldn't be a specific benefit to updating from the UI thread over any other thread, because all messages are enqueued regardless?

• I'd need more time probing; for example, Control's Text Property sets WindowText, which in turn is a Win32 SetWindowText call, so assuming the above changes were feasible, calls like this would need to be replaced with an equivalent PostMessage and/or handled differently.

Lastly:

• Let's presume there is some appeal to this proposal, but at the same time, there's concerns about the performance of using PostMessage vs. SendMessage (or other), might there be room for an option in the framework that would enable thread-safe Control mutation the way I'm suggesting vs. the current model? For example, we set CheckForIllegalCrossThreadCalls = false;, but that's dangerous (with the current model), what if we had another option, something like UseNewModel = true; that would both disable CheckForIllegalCrossThreadCalls, and simply turn methods into a SendMessage/PostMessage option, for example:

public bool Checked
{
    get
    {
        return isChecked;
    }

    set
    {
        if (isChecked != value)
        {
            isChecked = value;

            if (IsHandleCreated)
            {
                UseNewModel ? 
                    User32.PostMessageW(this, (User32.WM)User32.BM.SETCHECK, PARAM.FromBool(value)): 
                    User32.SendMessageW(this, (User32.WM)User32.BM.SETCHECK, PARAM.FromBool(value));

            }

            Invalidate();
            Update();
            PerformAutoUpdates(false);
            OnCheckedChanged(EventArgs.Empty);
        }
    }
}

If PostMessage isn't a suitable direct replacement for SendMessage (for whatever reason(s)), I wonder if "UseNewModel" could greatly simplify a vast majority WinForms apps, but still retain the current model for existing legacy code and (whatever reason(s) PostMessage isn't sufficient) purposes?

[weltkante]

Sorry, you are running off in an entirely wrong direction here. You cannot remove synchronization and expect programs to be still correct. SendMessage and Invoke are doing synchronization by waiting for the operation to complete and reporting back its result (be it a value or an exception). That is, all subsequent code can depend on the results of the invocation.

This isn't even related to threading synchronization, this is about the fact that operations are supposed to be executed in the order they are written. It is trivial to construct failing examples, under your updated proposal every reading operation will fail because writing operations are never executed (they are queued for execution).

As such your suggestion makes no sense at all anymore. Considering the proposal went off on a tangent that obviously can never work there is not much to continue to discuss. If its not yet clear to you why it cannot work I can only suggest experimenting more, for example try updating any reading operation with BeginInvoke or PostMessage and you should immediately run into problems. If you try to fix those problems you will run into the deadlock issues I mentioned earlier (these are not obvious though, so you may not immediately run into any deadlocks, but in order to report back results you have to wait for those results, and any cross thread waiting allows deadlocks to happen).

---

Are you referring to using SendMessage?

No, I was referring to Invoke vs. BeginInvoke, the win32 API is irrelevant.

Invoke has two fundamental features BeginInvoke doesn't have

• it waits for the operation to complete, allowing subsequent code to logically depend on the completion of the operation, making assumptions about the control state etc.
• it reports back exceptions and result values to the caller so the caller can consume them

Note that these are features, so they are not something you want to get rid of. You need these features for the program to do fundamental operations. Of course whenever you don't need those features you can use BeginInvoke.

However almost all operations in the WinForms API will need to report back results or exceptions so cannot use BeginInvoke (or PostMessage). They'll need to use Invoke (and SendMessage) and wait for the operation to complete, in order to report back any exceptions (and results) of the operation.

[Shidell]

Thanks for clarifying—it makes sense that Invoke and BeginInvoke both call MarshaledInvoke, and if called synchronously, it waits and reports the returned result.

I guess what still doesn't make sense is certain Properties, for example, Checked in CheckBox, or Minimum in ProgressBar. When mutating those Properties, they appear to just SendMessage, but never check the returned result. Because they aren't checking the returned result, would it make much difference to replace those SendMessages with PostMessage?

[weltkante]

When mutating those Properties, they appear to just SendMessage, but never check the returned result.

There is probably nothing to check, they wait for the operation to complete, and there is no failure case they are interested in. Just waiting for completion is enough to know the control is now in the state you want it to be in.

Because they aren't checking the returned result, would it make much difference to replace those SendMessages with PostMessage?

Yes, because callers may rely on the operation to have completed. If you use PostMessage then the native control will not match the state of the WinForms wrapper when the call returns.

For some cases the WinForms wrapper maintains its own mirror state so you don't immediately notice problems, but if anyone reads the native controls state he'd see the "old state" even though you just thought you updated it.

Consider the chaos you'd produce by setting SelectedIndex of a listbox via PostMessage, triggering a callback that the index changed, but anyone looking at the native control would see the old index still being in there - instead, at some arbitrary later point in time, the selected index would update without anyone getting notified.

Another example is when you have code doing user drawing for a native control, this is going to be pretty confusing for the drawing routines, because those are triggered from the native control not from the WinForms wrapper. When you change the controls settings it will still keep asking you to draw the old state until those PostMessage calls actually went through - this is going to confuse the callbacks since they'll look at the WinForms control and see control state not matching the arguments they received for drawing.

[Shidell]

Those are great examples, and really puts a focus on the issue at hand, and why Invoke and BeginInvoke are necessary.

Thanks much for taking the time to consider everything and respond in kind. I greatly appreciate it. :)