Partilhar via


Scalability and Multithreading

When a component has one thread of execution, code for only one object can execute at any given time. The Automation feature of the Component Object Model (COM) deals with this situation by serializing requests. That is, the requests are queued and processed one at a time until all have been completed.

In a multithreading operating environment, serialization protects single-threaded objects from overlapping client requests — that is, from code in a property or method being executed while one or more previous client requests are still being run. Overlapping requests can cause internal data errors if objects aren't designed for reentrancy.

Serialization is thus an extremely important feature of Automation. However, serialization of single-threaded components means that requests are sometimes blocked. For example, suppose you're using a Widget object that has two methods, spin and flip.

  • The Spin method takes anywhere from several seconds to half an hour to complete.
  • The Flip method is almost instantaneous.

Because 32-bit applications are preemptively multitasked, a second application could call the Flip method while the Spin method is already running. The short Flip method is blocked until the long Spin method is complete.

When short operations are blocked by long ones, productivity suffers and user frustration rises. Components that behave in this fashion are said to scale poorly. That is, they work poorly if many requests of mixed length are made.

Visual FoxPro provides two component features to address scalability and avoid blocked calls — SingleUse instancing and multithreaded objects. For details, see Controlling Call Blocking.

See Also

Early (vtable) and Late (IDispatch) Binding | Visual FoxPro Run-Time Libraries | Interoperability and the Internet | Compiling Source Code