The Old New Thing

I'm sure that the basics of what you are saying is documented in MSDN.  However, I've always been the type of person who understands things better knowing the "why".

Of course, with pure contract programming, why isn't really important.

Thanks for the info.

I think that understanding "Why" helps you truly understand the "What", and makes you less likely to inadvertently make mistakes.  You're also probably more likely to guess correctly in areas where the contract isn't well-defined.

That, combined with the fact that STA threads are required to pump messages, is why non-UI threads should be MTA, while UI threads should be STA. Unfortunately Visual Studio .NET defaults to STA even for console apps.

"Compatibility with this ancient model still exists today, thanks to the dreaded "main" threading model."

VB ActiveX DLLs and controls used that threading model before a SP (3?) to VB 5 added support for the STA threading model.

BTW, when was multi-threading support and the associated threading models added to COM? This is important if you are programming for Windows 95 or NT 3.5.

Best explanation of the difference between STA and MTA I've ever read.

Why is why important?

It depends on how your brain is wired.

For example, when I was getting my math degree, I had trouble remembering all those diverse formulas and rules.  However, by understanding the theory behind them, I could always re-derive the formulas because I understood the whys.  In many ways it provides a higher level understanding.

This is what is known as insane by design.

And now you all know why so few people even try to write multi-threaded code.  If the basic synchronization and communication tasks don't get you, strange terms and stranger design choices will.

Xepol: how would you have designed multi-threaded COM in 16-bit Windows, then?

Xepol,

I've been doing multithreading programming for many many years.  Yes, many new people make the mistake of trying to do the UI from non-UI threads, but that is an easy lesson to learn.  But after you learn that lesson, the complexity of doing multithreaded code is huge compared to this lesson.

Complexity of multithreaded code: infinity

Complexity of multithreaded UI code: infinity+1

In other words, if people are having trouble doing multithreaded UI code, they are also going to have trouble doing multithreaded code in general.  The UI aspect of it doesn't add much complexity at all.

"how would you have designed multi-threaded COM in 16-bit Windows, then?"

I would have thrown it overboard when switching to Win32 and designed something more straight.

But we have heard time and time again how backward comatibility right into the palaeolithic was the one fixed requirement in the design of Windows.

Multi-threaded code isn't so hard, but you need to understand the constraints and methods used for synchronising threads.  The Windows messaging structure doesn't support multiple threads and the Windows GDI gets messed up when GDI objects are allocated in one thread and deleted in a different thread. So for an app to benefit from multi-threading, the primary/UI thread runs apartment threaded and the background / worker threads run multi-threaded.  To avoid the major headaches have only the primary/UI thread pump windows messages, create windows and do GDI drawing calls.  The background threads can churn along and but not directly update the UI.  A simple technique I like to use for updating the UI after background threads have delivered data that can be used to update the UI is to use InterlockIncrement() to update a "this bit of the use needs to be updated" count.  Back on the UI thread a timer ticks -- say once every 1/30 a second and checks the "this bit of the ui is dirty" counts and repaints / updates the UI as needed and clears the dirty count.  Simple, but effective.

But polling is bad! Last time i checked, the events API can be used perfectly across threads.

http://blogs.msdn.com/oldnewthing/archive/2006/01/24/516808.aspx

"right into the palaeolithic"

When this stuff was designed, the palaeolithic was last week.

It's true that events can be used.  However the are some advantanges to the simpler technquies.   1st of all human perception limits how frequently it is useful to update the UI -- visual updates that happen more closely spaced that 1/30 will not be detetcable by the human eye.   2nd -- "poling is bad" is a broad generalization -- the method I'm suggesting isn't actually poling in the typical sense.  

Using an event based model -- if five background tasks complete in one 1/30 second interval -- the UI will get repainted 5 times.   Using the "repaint UI periodcially when marked dirty" model -- in the same circumstance the UI will get painted only once -- as far a human observer is concerned -- there is no detetable difference -- but the latter approach makes more system resources availble to the background tasks.

"as far a human observer is concerned -- there is no detetable difference -- but the latter approach makes more system resources availble to the background tasks."

Don't be so sure about that. Instead of haphazardly guessing how good the users' eyes are, you should use the best measurement available: The monitor refresh rate. The most efficient UI model is one where the screen is not redrawn unless there has been a change in the contents, and the most recent redraw was within the last monitor refresh. Obviously nobody would bother to implement the whole thing on their own, however if microsoft added it to a library so third parties could use it, it could be quite efficient (And would fit very neatly into the Vista window managers' double buffering scheme)

In general, it is important that any code in a managed Office add-in should execute on the main UI thread.