COM Threading and Application Architecture in COM Applications Michael McKeown Support Engineer Solu

1
COM Threading and Application Architecture in
COM Applications Michael McKeownSupport
Engineer Solution Integration Engineering
(SIE)Microsoft Corporation
2
What Well Discuss

• COM improvements
• Neutral threading model
• Threading model recommendations
• Server components and threading

3
COM ImprovementsJust-in-time Activation (JIT)

• Code
• IObjectContextSetAbort/SetComplete
• IContextStateSetDeactivateOnReturn(TRUE)
• Component Services explorer
• Component level Enable just in time activation
• Forces Synchronization Required
• Enabled if transactions checked
• Method level auto-done property
• Deactivate this object when this method returns

4
Object Pooling

• Generic instances shared at class level
• Cannot cache user-specific state
• Reuse expensive resources
• Save time during activation
• Setting in COM Services
• Cannot have thread affinity
• IObjectControlCanBePooled
• JIT vs. object pooling

5
Synchronization

• Logical boundary around mutually synchronized
  components
• Example Required and Supports
• Set to Required if JIT or transactions
• Only one thread at a time runs within this
  synchronization boundary
• Synchronization determines when this can occur
• Previously, apartments dictated this under
  Microsoft Windows NT

6
Synchronization (2)

• In COM, maps to synchronization setting
• If none selected (and no JIT or TXs), component
  manages all its synchronization and can be called
  anytime
• A COM synchronization can span many apartments
  and contexts
• A context/apartment can exist in only one
  synchronization
• Can span processes ONLY if you enforce it in your
  component architecture via call tree graph

7
Understand Call Tree Frequencies

• Pay careful attention to
• How a component will be used in call tree graph
• Avoid blocking and odd behavior
• Call only those components it instantiates
  directly or those instantiated below them in the
  tree
• Avoid passing component references up or across
  the call tree
• Avoid multiple callers into the same component
• Simplifies everything and is inherently scalable
• From what type of apartment the component will be
  called
• Dont just blindly mark as Both or Free

8
Understand Call Frequencies

• Example A creates B, which creates two
  Apartment components C and D
• If A and B have many calls between themselves,
  but B has few calls between C and D
• B should be Both to create in As apartment
• If A and B have few calls between themselves, but
  B has many calls between C and D
• B should match threading model of C and D
• If B is Both and A lives in STA, B will run as
  STA and in same apartment as C and D GOOD.
• However, if A lives in MTA, and B is Both, it
  will run as Free and live in MTA BAD!
• Thus, mark B as Apartment to be close to C and D

9
Contexts

• Set of run time attributes (Tx, Sync, etc.)
• Tells COM what the required interception
  services are
• Term context has roots in MTS
• Context wrapper replaced by intelligent stub
• Policy sets (interception)

MTS
Client
Proxy
Stub
CW
JIT instance
COM
COM
Policies / interception
10
Contexts (2)

• Each instance has a context
• Shares activators context if all attributes
  compatible
• Calls in the same context are direct
• Configured components rarely share context
• JIT, Synchronization, and transaction settings
• Certain threading model values (Apartment vs.
  Free)
• Incompatible contexts will be swapped (marshaled)
  from activator to component
• Allows for different interception service
  requirements
• Lightweight proxy (discussed later)

11
Contexts (3)

• Can be more than one context in an apartment
• A context lives in only one apartment
• Default context
• Unconfigured components with compatible threading
  model with their activator
• One default context per apartment
• Non-default context
• Configured components with compatible attributes
• Typically more than one per process

12
Contexts in a Windows 2000 Apartment
13
Compatible Contexts

• Logical boundary around instances with compatible
  extended attributes
• Attributes are service-specific plus threading
  model
• Transactions, Synchronization, JIT
• Example Component A creating component B
• Component A Tx Required and Sync Required
• Component B Tx Supports and Sync Not
  Supported
• Note Both components can share a transaction
  boundary, but not a synchronization boundary
• Live in different contexts

14
Compatible Contexts (2)

• CA and CC are in different apartments, but may
  be sharing a TX boundary
• CA and CB share an apartment boundary AND may be
  sharing a sync boundary
• CC and CE are in different processes, but may be
  sharing a Tx boundary

P-A
A-A
A-B

CA
CC
A
D
B
CB
C
Process
P-B
A-C

CE
Apartment
G
CD
E
Context
F
Boundary
15
Object Context

• Unique to each component instance
• Basically same dual role as under MTS
• Data structure to hold attributes such as
• TX ID, Synchronization ID, SIDS, etc.
• Service component that offers COM services to
  configured components
• CoGetObjectContext replaces legacy
  GetObjectContext
• Allows access to new COM service interfaces
• IObjectContext, IObjectContextInfo,
  IObjectContextActivity, IContextState

16
Object Context (2)
struct OBJECT_CONTEXT IObjectContextInfo,
IContextState, IObjectContext, ... //
context properties GUID id // ID of this
context SYNCHRONIZATION pSync APARTMENT
pApt bool bJITAEnabled bool bDone long
nCallsInProgress IUnknown pPrimaryObject
TX_STREAM pTxStm bool bRootOfStream bool
bHappy // interface methods deleted for clarity

17
Interception and Proxies

• Direct interface pointer (same apartment and
  context)
• Threading model and contexts compatible
• No interception
• Lightweight proxy (same apartment / different
  context)
• No thread switch (executes on callers thread)
• Marshals interfaces only
• Interception services
• Traditional proxy (different apartment or
  process)
• Most expensive
• Thread switch
• Marshals interfaces and parameters
• Interception services

18
Apartments in Windows 2000

• No longer the innermost execution scope of an
  object for configured components
• Contexts have assumed this role
• Maps specific threads to contexts
• Determines which threads can call an object, not
  when a thread can call an object
• Synchronization attribute now determines when

19
Contexts, Apartments, and Synchronizations Summary

• Contexts
• Determine services required for method call
• Belong to one apartment, but can be more than one
  different context in an apartment
• Belong to at most one synchronization only
• Apartments
• Contain one or more contexts
• Determine which threads can call an object
• Synchronization can span multiple apartments
• Each apartment exists on only one synchronization

20
Contexts, Apartments, and Synchronizations
Summary (2)

• Synchronizations
• Typically span apartments and contexts
• Ensure when serialization of calls to all
  components in the same synchronization
• Every context belongs to at most one
  synchronization
• If no sync, context does not belong to any
  synchronization

21
Threading Terminology

• Apartments
• Single-threaded apartment STA
• Multithreaded apartment MTA
• Neutral apartment (no threaded) NA
• Confusing component terminology
• Example OCX versus ActiveX control
• x theaded component
• x Apartment, STA, Free, MTA, Neutral
• Proper component terminology
• y component or component marked y
• y Apartment, Free, Both, Neutral registry values

22
COM Threading

• Components dont live on threads
• An instance is a chunk of memory associated
  with an apartment
• Apartments determine which threads can call the
  component
• Thread switch is decided by the proxy based on
  apartment and threading model

23
Neutral Threading Model

• Basically a Both object
• FTM-like marshaling capabilities for configured
  COM components
• Cross apartment (same process) used to require a
  thread switch
• Method calls from any apartment (same process)
  type without thread switch
• Methods execute in the (logical) Neutral
  apartment (NA), but on the calling apartments
  thread
• COM gives back standard proxy to Neutral objects
  for context switch and marshaling

24
Neutral Threading Model (2)

• One Neutral Apartment (NA) per process
• COM creates the NA when required
• NA is neutral and not bound to any threads
• No threads are bound to the NA
• Threads dont enter the NA like MTA/STA
• No CoInitializeEx(COINIT_NEUTRAL)

25
Neutral vs. BothAlmost Identical

• Operate well in Both an MTA and STA environment
• Thread safe via synchronization primitives for
  MTA
• Globals, statics, and members
• Nothing thread specific
• TLS, Windows handles, or code logic that assumes
  it is always being called on same thread
• No operations that block STA message pump
• Explicit calls to WFSO / WFMO avoided
• Use new CoWaitForMultipleHandles
• If called by STA, will enter loop during wait and
  pump messages
• If called by MTA, will map to WFMO

26
Neutral vs. BothYet Different

• Differ in ability to store interface pointers
  within the class instance data
• Both with FTM cannot store interface pointers
• Direct pointer passed across process without COM
• Neutral components can store interface pointers
• A standard proxy is returned never direct
  pointer
• COM ensures stored interface pointers in passed
  objects instance data called on correct thread

27
Threading Recommendations

• Minimize mixed threading models
• Instantiate component as close to activator as
  possible
• Same apartment and same context if possible
• Understand ramifications of extended attributes
• Minimize thread switching if possible
• Dont sacrifice COM functionality just to shave
  a few milliseconds!

28
Apartment Components

• Recommended for MTS, but avoid in COM (unless
  called from ASP)
• Unnecessary hidden window and marshaled calls
  through message loop
• Will force Sync Required
• Serialization through synchronization for
  configured components
• Best for page scope in ASP
• Dont store it in Session or Application scope

29
Free Components

• For components making blocking calls
• Implicitly during outgoing calls outside
  apartment or process
• Explicitly using WFMO, WFSO, etc.
• Not recommended for MTS
• Wasted synchronization code and cross-apartment
  marshaling
• Great for DCOM and straight COM
• Okay for COM pooled objects (Neutral is better)
• Not good if called from ASP (configured or not)
• Better than Apartment if using JIT
• Methods still serialized on synchronization lock,
  but not in MTA

30
Both Components

• Tastes good and is less filling
• Runs well in both STA and MTA
• Better than Free because good for ASP
• Run as Apartment under ASP
• Just as good as Free for DCOM COM
• Unconfigured Both activated in creators context
• Key point MTA side must not ruin STA and vice
  versa

31
Neutral Components

• Like Both, but no thread switch
• Can store interface pointers in instance data
• Good in situations where different types of
  apartments are calling a single component
• Avoid many-to-one in server environment
• Good in common local applications doing logging
• Best for COM pooled objects

32
Server Components

• MTS (STA activator threads)
• Use Apartment or Both and avoid Free
• Marshaling into MTA and unnecessary sync
  primitives
• ASP (Runs as STA)
• Use Apartment at page scope
• Free has usual STA issues, plus
• Security issues of proxy

33
Server Components (2)

• DCOM (No ASP or COM)
• Incoming DCOM requests
• If its an Apartment component, it will block the
  request until its specific thread is available
• If its a Free component, call can be transferred
  to first available thread and no waiting
• DCOM objects should be Free
• Neutral does not matter in remote case
• Neutral has limitation of not blocking calls

34
Server Components (3)

• DCOM (with COM)
• Free is best because of COM MTA thread pool
• Neutral is okay
• No thread switch is insignificant remotely
• Code to make it behave in STA could be hindrance

35
ASP Components

• ASP session-scoped components (Agile)
• Windows NT Both with FTM
• Windows 2000 Cannot aggregate FTM because cannot
  allow direct call, so choose Neutral
• ASP application-scoped components
• Avoid if at all possible because blocking is
  worse than at session scope
• IIS 5.0 will not allow Apartment to be assigned
  to an Application variable

36
Wrap Up

• COM improvements
• Threading terminology
• Neutral threading model
• Threading model recommendations
• Server components

37
(No Transcript)