re: More on Multithreaded UI in WPF

JGalasyn — Tue, 01 May 2007 23:24:03 GMT

Hi Udi, thanks for your question. I don't think WPF provides anything fundamentally new, except for the Dispatcher and the System.Windows.Threading namespace. For more on the WPF threading model, see "Threading Model" (http://msdn2.microsoft.com/en-us/library/ms741870.aspx).

The .NET Framework provides other options than those in the System.EnterpriseServices namespace, which iirc is mostly about wrapping COM+/MTS components in managed wrappers.

Here's a quick list of resources which describe the threading options in the .NET Framework.

Asynchronous Programming Design Patterns

http://msdn2.microsoft.com/en-us/library/ms228969.aspx

Threading Design Guidelines

http://msdn2.microsoft.com/en-us/library/f857xew0.aspx

Managed Threading Best Practices

http://msdn2.microsoft.com/en-us/library/1c9txz50.aspx

The most interesting new players (.NET 2.0) may be these:

BackgroundWorker

http://msdn2.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx

Event-based Async Pattern

http://msdn2.microsoft.com/en-us/library/hkasytyf.aspx

I hope you find these topics helpful, and thank you for reading my blog.

Jim

re: More on Multithreaded UI in WPF

Udi Dahan — Tue, 01 May 2007 22:53:54 GMT

Client-side multi-threading is something I do day-in, day-out, and I have to say that the whole treatment of thread-safety for data held/cached on the client is rather poor.

The only thing we have today (and I mean since .NET 1.0, and apparently going into 3.5) is the SynchronizationAttribute placed on classes that inherit from ContextBoundObject. Of course, this comes with a huge performance penalty.

Is there something that WPF does that doesn't appear at the BCL level?