User interface code + multi-threaded apartment = death

re: User interface code + multi-threaded apartment = death

Tim Smith — Thu, 24 Apr 2008 18:09:24 GMT

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.

re: User interface code + multi-threaded apartment = death

David Walker — Thu, 24 Apr 2008 18:21:28 GMT

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.

re: User interface code + multi-threaded apartment = death

Yuhong Bao — Thu, 24 Apr 2008 18:30:11 GMT

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.

re: User interface code + multi-threaded apartment = death

Yuhong Bao — Thu, 24 Apr 2008 18:52:29 GMT

"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.

["The less said about that threading model the better." -Raymond]

re: User interface code + multi-threaded apartment = death

Yuhong Bao — Thu, 24 Apr 2008 22:05:26 GMT

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.

re: User interface code + multi-threaded apartment = death

jon — Thu, 24 Apr 2008 22:21:03 GMT

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

re: User interface code + multi-threaded apartment = death

Tim Smith — Fri, 25 Apr 2008 00:44:31 GMT

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.

re: User interface code + multi-threaded apartment = death

Xepol — Fri, 25 Apr 2008 04:11:14 GMT

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.

re: User interface code + multi-threaded apartment = death

Dean Harding — Fri, 25 Apr 2008 05:38:10 GMT

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

re: User interface code + multi-threaded apartment = death

Tim Smith — Fri, 25 Apr 2008 17:25:14 GMT

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.

re: User interface code + multi-threaded apartment = death

noone in particular — Fri, 25 Apr 2008 18:01:10 GMT

"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.

re: User interface code + multi-threaded apartment = death

RandyOakley — Fri, 25 Apr 2008 23:55:12 GMT

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.

re: User interface code + multi-threaded apartment = death

!bofh — Sat, 26 Apr 2008 12:44:28 GMT

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

re: User interface code + multi-threaded apartment = death

Sun, 27 Apr 2008 07:15:25 GMT

"right into the palaeolithic"

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

re: User interface code + multi-threaded apartment = death

RandyOakley — Mon, 28 Apr 2008 19:47:29 GMT

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.

re: User interface code + multi-threaded apartment = death

Triangle — Mon, 28 Apr 2008 20:05:03 GMT

"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)

Why your COMAddIn.Object should derive from StandardOleMarshalObject

Andrew Whitechapel — Tue, 12 Aug 2008 00:31:30 GMT

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