Advertisement
ivandrofly

What are the differences between `SynchronizationContext` and `SynchronizationContextNoFlow`

Aug 17th, 2023 (edited)
132
0
Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
text 1.95 KB | None | 0 0
  1. In .NET, SynchronizationContext is a fundamental concept that is used for propagating various kinds of application context across different parts of the application, e.g., between threads or between an asynchronous operation and its completion callback.
  2. SynchronizationContext basically provides a way to queue a delegate to be run on some context. For instance, SynchronizationContext.Current will be a DispatcherSynchronizationContext on a WPF UI thread, so calling its Post method will enqueue the delegate to the UI thread's dispatcher.
  3. The details of GetExecutionContextReader().SynchronizationContext and GetExecutionContextReader().SynchronizationContextNoFlow are not publicly documented as part of the .NET BCL (Base Class Library) or CoreCLR open source libraries. Furthermore, Thread.CurrentThread.GetExecutionContextReader() is an internal method that cannot be invoked directly.
  4. Though their differences is not clearly defined, here is an educated explanation:
  5.  
  6. SynchronizationContext: As outlined above, the SynchronizationContext is the synchronization context associated with the current ExecutionContext. It can transfer its context when executing tasks or threads, and serves as a sort of implicit parameter for some operations.
  7.  
  8. SynchronizationContextNoFlow: The NoFlow part, from its name, seems to suggest that this particular SynchronizationContext will not flow the context to a child operation. This essentially means that when you create a new thread or task, this context wouldn't automatically be used by that new thread or task.
  9.  
  10. Please note that the details of these properties are dependent on implementation details of the .NET runtime which might change between versions or even in minor updates, and also behave differently across different platforms. If you have a particular usage in mind, it might be better to think more in terms of higher-level abstractions built on top of these primitives (like Task, etc.) as they offer a more stable API to work with.
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement