You can cause each instance of an OLEPUBLIC class to run in a separate instance of your component by setting the Instancing property of the OLEPUBLIC class to SingleUse in the Project Info dialog box. This means that even though your component is single-threaded, each instance of the SingleUse class has its own thread of execution. The behavior of SingleUse objects differs between .exe and .dll servers.

Visual FoxPro Automation servers now support Apartment-model threading. The Microsoft Transaction Server utilizes servers marked as apartment-threaded and offers better thread protection and scalability through serialization and marshaling.

In Visual FoxPro, apartment-model threading provides thread safety. In apartment-model threading, each thread is like an apartment — all objects created on the thread live in this apartment, and are unaware of objects in other apartments. Each Apartment-model object (such as a Visual FoxPro Automation server) may only be entered by one thread, the thread that created the object. However, an object server (such as Microsoft Transaction Server) can support multiple objects, each being entered simultaneously by different threads. Common data held by the object server must be protected against thread collisions.

Apartment-model threading provides the following benefits:

• All of the objects a client creates on a given thread are created in the same apartment (thread) in the DLL. Calls on the same thread to these objects do not require cross-thread marshaling, making them more efficient.
  
  
• Because an object is only accessed on the thread on which it was created, calls are serialized so that a call is never interrupted by a call from another thread.
  
  
• Arguments for cross-thread calls are marshaled, and the calling thread is blocked. This synchronization of data protects the calling thread's state.
  
  

Apartment-threaded DLLs cannot create their own threads; the first time a client thread requests an object provided by your DLL, a new apartment is created, and the object Init event runs for that apartment. All single threaded client objects requested by that client will reside in the same apartment, and will share global data. Any PRIVATE objects (including forms) that are created by the public objects will also reside in the apartment.

Though Visual FoxPro does not provide a way for apartments to access each other, a multithreaded client could obtain a reference to an object on Thread A, and pass that reference to an object on Thread B.

For more information about Apartment-model threading, search on "Apartment-Model Threading" in the MSDN library.

The Visual FoxPro implementation of Apartment-model threading eliminates conflicts in accessing global data from multiple threads by giving each apartment its own copy of global data. This means that all objects created on the thread exist in this apartment, and are unaware of objects in other apartments.

Visual FoxPro uses thread local storage to store a unique set of application and environment global data for each thread (apartment). This means that two instances of the same class created on different threads cannot access each other's data. However, if these same two instances reside on the same thread, each object can access the other's data. This could cause timing issues for your applications. In fact, as long as two objects on the same thread are created from OLEPUBLIC classes in the same .dll server, data from those objects is common between them (Note: You can use the Session class to give each object a unique private datasession.)

In addition to thread local storage, Visual FoxPro also provides each project (.dll) a unique set of globals data. Objects created from different projects (.dll servers) cannot access each other's globals, even if the two objects reside on the same thread.