none
Is SynchronizationContext using InvokeRequired? RRS feed

  • Question

  • Hi,

    When using Invoke you usally also check the InvokeRequired, how does this work with SynchronizationContext (Send/Post)? Will it internally check InvokeRequired or is it more or less the same as just running Invoke/BeginInvoke and no InvokeRequired check?

    Monday, April 28, 2014 8:51 AM

Answers

  • "Okay, so in a WinForm application there is no real advantage to use SynchonizationContext.Send compare to Control.Invoke?"

    Well, as I said, it is useful in writing code that doesn't depend on WinForms specific functionality. If you don't care about this then I don't think SynchronizationContext has any advantages for you.

    There's on very specific case where SynchronizationContext is somewhat better than Invoke.

    People tend to use whatever control they have around for Invoke/BeginInvoke. If that control is disposed while a background thread is trying to call Invoke/BeginInvoke when you're likely to get a ObjectDisposedExecption. For example, this can happen if the user closes a (dialog) form and the code doesn't attempt to stop background threads that may have been started by that form.

    SynchronizationContext avoids this because it uses a control that has been specially created for it and that control is not disposed until the application exits. That doesn't mean that SynchronizationContext avoids the issue completely, you can still get an exception if the application exits while a background thread is running...

    Personally I don't like Invoke/BeginInvoke exactly because it is tied to controls instead of threads. But if I were to make a best practice recommendation I think I'll recommend using BackgroundWorker instead of using SynchronizationContext directly. BackgroundWorker using the synchronization context under the covers and offers a number of additional features like progress reporting and exception handling. 

    • Marked as answer by SnowJim Monday, April 28, 2014 11:53 AM
    Monday, April 28, 2014 11:36 AM
    Moderator

All replies

  • please see this msdn article on this.

    hope this helps!

    Monday, April 28, 2014 9:10 AM
  • Thanks, already read that and did not find any information about if InvokeRequired is used or not?
    Monday, April 28, 2014 9:16 AM
  • Nope, it doesn't check InvokeRequired. In general, checking InvokeRequired is a rather strange thing to do, it means that you don't know what thread is your code running on.

    Monday, April 28, 2014 9:21 AM
    Moderator
  • But if is not, what is the the diffrence on running just control.Invoke instead of SynchronizationContext.Post?

    Yes I know about the context and what it is good for but if I got a control that I can run Invoke on or just use the SynchonizationContext.Post.


    • Edited by SnowJim Monday, April 28, 2014 10:05 AM
    Monday, April 28, 2014 10:00 AM
  • You probably wanted to say Invoke/Send or BeginInvoke/Post. Yes, they do the same thing, WinForms implements SynchronizationContext by using Invoke and BeginInvoke.

    The nice thing about about SynchronizationContext is that it isn't WinForms specific, code that makes use of SynchronizationContext can also be used in WPF. WPF provides its own implementation based on Dispatcher.Invoke.

    That said, I've rarely seen people using SynchronizationContext in WinForms, partly because they're used to Invoke, partly because it is perceived as being more complicated.

    Monday, April 28, 2014 10:27 AM
    Moderator
  • You probably wanted to say Invoke/Send or BeginInvoke/Post. Yes, they do the same thing, WinForms implements SynchronizationContext by using Invoke and BeginInvoke.

    The nice thing about about SynchronizationContext is that it isn't WinForms specific, code that makes use of SynchronizationContext can also be used in WPF. WPF provides its own implementation based on Dispatcher.Invoke.

    That said, I've rarely seen people using SynchronizationContext in WinForms, partly because they're used to Invoke, partly because it is perceived as being more complicated.

    Okay, so in a WinForm application there is no real advantage to use SynchonizationContext.Send compare to Control.Invoke?

    I have seen some that says that SynchonixationContext is best practice but I never read it on MSDN papers.

    Monday, April 28, 2014 10:59 AM
  • "Okay, so in a WinForm application there is no real advantage to use SynchonizationContext.Send compare to Control.Invoke?"

    Well, as I said, it is useful in writing code that doesn't depend on WinForms specific functionality. If you don't care about this then I don't think SynchronizationContext has any advantages for you.

    There's on very specific case where SynchronizationContext is somewhat better than Invoke.

    People tend to use whatever control they have around for Invoke/BeginInvoke. If that control is disposed while a background thread is trying to call Invoke/BeginInvoke when you're likely to get a ObjectDisposedExecption. For example, this can happen if the user closes a (dialog) form and the code doesn't attempt to stop background threads that may have been started by that form.

    SynchronizationContext avoids this because it uses a control that has been specially created for it and that control is not disposed until the application exits. That doesn't mean that SynchronizationContext avoids the issue completely, you can still get an exception if the application exits while a background thread is running...

    Personally I don't like Invoke/BeginInvoke exactly because it is tied to controls instead of threads. But if I were to make a best practice recommendation I think I'll recommend using BackgroundWorker instead of using SynchronizationContext directly. BackgroundWorker using the synchronization context under the covers and offers a number of additional features like progress reporting and exception handling. 

    • Marked as answer by SnowJim Monday, April 28, 2014 11:53 AM
    Monday, April 28, 2014 11:36 AM
    Moderator