OOM.NET: Part 4 - Don't Thread On Me

Patrick posted a discussion of multithreading with Outlook Object Model and why it doesn't help to make OOM calls on a seperate thread...

"Outlook Object Model is run in a STA COM server. This means that all OOM calls are executed on the main thread...You don't gain any performance [when multithreading] because all the calls are going to run on the same thread anyway and you incur the overhead hit of doing the marshaling to begin with, so there's not really an advantage to multithreading Outlook Object Model."

The typical scenario is a VSTO or .NET Shared AddIn for Outlook that wants to do some kind of "background" processing of items in a seperate thread as to not hold up the UI. This other thread will have OOM code in it that loops through items, folders, or both. This is the kind of thread that actually hurts performance - using OOM on a seperate thread rather than the main thread. If an AddIn makes use of seperate threads for working with things outside Outlook such as a database, filesystem, etc. then these recommendations don't apply necessarily.

Creating new threads and even marshalling between them is pretty easy in .NET and like many things in .NET (and VB6 before it) is that this marshalling and threading is supposed to "just work". Developers can get a lot of this working with out really understanding what is going on and what is required to make this work. An understanding of COM and what it means to STA like Outlook Object Model is required to come to the conclusions in Patrick's post.

Comments

• Anonymous
  March 14, 2008
  Gaps found in Microsoft Exchange API documentation Windows Server 2008 & Exchange Backup I do not