Minh said:
wkempf said:
*snip*
I think it's entirely based on performance. Perhaps the Win32 limitation impose a too heavy a performance penalty on automatic synch... but how is Silverlight able to do it?

Deadlock is only a possibility when you try to take out locks while already holding locks, right? It's too bad that even until now (for the exception of Silverlight), we still don't have a good solution for this problem.
The synchronization employed here is a "context switch via message queue".  Said message queue is one large lock.  I've seen code attempt to do automatic synchronization in this fashion, and it frequently results in deadlock.

I've got no clue how (or if) Silverlight does automatic synchronization.  As someone who knows a lot about multi-threading, though, I can tell you that automatic synchronization is terrible for performance and can often lead to hard to discover dead locks.  That statement is relevant beyond the UI synchronization we're talking about here.

Edit:  The first page I hit on Google suggests that Silverlight uses the exact same threading model that WPF does.  http://www.wintellect.com/CS/blogs/jprosise/archive/2008/03/26/threading-and-marshaling-in-silverlight-2-0.aspx

This is not automatic synchronization.