101 reputation
1
bio website
location
age
visits member for 1 year, 6 months
seen Jan 31 at 9:08

Feb
11
awarded  Supporter
Dec
21
comment How will C# 5 async support help UI thread synchronization issues?
Even if we pretend that a SynchronizationContext is effectively not a synchronization context, the MSDN mag article points out AspNetSynchronizationContext as used by ASP.NET does exclusion of simultaneous execution (which you'd surely concede is a form of synchronization) without without being bound to a specific thread. Synchronization contexts are after all about synchronization, not about thread picking. The point stands.
Dec
20
comment How will C# 5 async support help UI thread synchronization issues?
Check again, the second gist above (this one: gist.github.com/4334891 ) explicitly sets a synchronization context above via SetSynchronizationContext on the thread pool thread in question to make the point more explicit. Your Console.WriteLine does NOT print null after such a call, yet it DOES still exhibit identical thread hopping behavior.
Dec
19
comment How will C# 5 async support help UI thread synchronization issues?
Further down if you Ctrl+F for "Summary of SynchronizationContext Implementations" you'll see a comparison table also showing "No" for "Specific Thread Used to Execute Delegates" x "Default". And of course, these are only the built in sync contexts, nevermind user defined ones.
Dec
19
comment How will C# 5 async support help UI thread synchronization issues?
As for references, msdn.microsoft.com/en-us/magazine/gg598924.aspx notes that "Thus, UI applications usually have two synchronization contexts: the UI SynchronizationContext covering the UI thread, and the default SynchronizationContext covering the ThreadPool threads." -- updated example using FromCurrentSynchronizationContext explicitly here: gist.github.com/4334891
Dec
19
comment How will C# 5 async support help UI thread synchronization issues?
While I don't yet grok ConfigureAwait's underpinnings, it's probably pointless if you're already on the thread pool, and would make sense only for UI threads. If you see this sample: gist.github.com/4334796 -- message boxes will spam after pressing the button once because the default sync context of the thread pool allows execution to continue on any thread of the pool. They'll disappear if you remove the wrapping ThreadPool.QueueUserWorkItem, because it then uses the default sync context of the UI thread, which limits execution to the UI thread.
Dec
18
comment How will C# 5 async support help UI thread synchronization issues?
Sync contexts are a bit harder to explain/grok, evidenced by a minor error in your answer: the default sync context of the thread pool executes callbacks on the thread pool in general, not necessarily "on whichever thread called the FromCurrentSynchronizationContext method". Potentially an important distinction if you're accessing thread local storage!