Steuerung der Aufrufblockierung

Um die Skalierbarkeit einer Anwendung zu erhöhen, stellt Visual FoxPro SingleUse-Objekte und das Apartmentmodell-Threading als Methoden zur Steuerung der Aufrufblockierung zur Verfügung.

SingleUse-Objekte

Wenn Sie in dem Dialogfeld Projektinfo die Instancing-Eigenschaft einer als OLEPUBLIC definierten Klasse auf den Wert SingleUse festlegen, hat dies zur Folge, dass jede Instanz der Klasse in einer eigenen Instanz der Komponente ausgeführt wird. Das bedeutet, dass auch bei Singlethread-Komponenten jede Instanz der SingleUse-Klasse über einen eigenen Ausführungsthread verfügt. Für EXE- und DLL-Server weisen SingleUse-Objekte ein unterschiedliches Verhalten auf:

SingleUse-Objekte in EXE-Servern

Wenn die Instancing-Eigenschaft auf den Wert SingleUse festgelegt wird, veranlasst jede Instanz die Aufnahme eines neuen EXE-Prozesses (unter Windows NT 4.0 oder höher können Sie jeden ausgeführten Prozess im Task-Manager anzeigen). Wird die Einstellung MultiUse verwendet, veranlasst die erste Instanz die Aufnahme eines neuen Prozesses; jede weitere Objektinstanz verwendet jedoch denselben Prozess wie die erste Instanz.

SingleUse-Objekte in DLL-Servern

Die Instancing-Eigenschaft wird bei Multithread-DLLs ignoriert und wird nur von der Laufzeitbibliothek Vfp7r.dll gelesen. Server, bei deren Erstellung angegeben wird, dass sie die Laufzeitbibliothek vfp7t.dll verwenden, weisen ungeachtet der Instancing-Eigenschaft immer das Attribut MultiUse auf. Für prozessinterne Server, die vfp7r.dll verwenden, sollten Sie die Instancing-Eigenschaft normalerweise immer auf MultiUse festlegen. Wenn Sie die Eigenschaft auf SingleUse festlegen, kann nur eine Instanz eines Objekts von diesem Server erstellt werden. Beim Versuch, weitere Objekte zu instanziieren, wird ein Fehler ausgegeben. Nur in sehr seltenen Fällen ist die Verwendung der SingleUse-Einstellung notwendig. Für Microsoft Transaction Server-Komponenten ist die MultiUse-Einstellung erforderlich. SingleUse-Objekte benötigen häufig mehr Arbeitsspeicher als mehrere Objekte in einer Multithread-Komponente.

Die Verwendung von SingleUse-Objekten kann jedoch unter bestimmten Bedingungen erforderlich oder wünschenswert sein. So können Sie mit SingleUse-Objekten beispielsweise sehr risikoreiche Vorgänge in separaten Prozessen isolieren. Wenn für das Objekt ein schwer wiegender Fehler auftritt, wirkt sich dies nicht auf andere Prozesse aus. Im Gegensatz dazu führt ein schwer wiegender Fehler in einer Multithread-Komponente dazu, dass alle Threads beendet werden.

Apartmentmodell-Threading

Visual FoxPro-Automatisierungsserver unterstützten jetzt das Apartmentmodell-Threading. Microsoft Transaction Server verwendet Server, die als Apartmentthread-Server gekennzeichnet sind, und bietet durch die Serialisierung und das Marshalling einen besseren Threadschutz und eine bessere Skalierbarkeit.

In Visual FoxPro wird die Threadsicherheit durch das Apartmentmodell-Threading gewährleistet. Beim Apartmentmodell-Threading verhält sich jeder Thread wie ein Apartment. Alle Objekte, die in dem Thread erstellt werden, befinden sich in diesem Apartment und wissen nichts von der Existenz von Objekten in anderen Apartments. Jedes Objekt im Apartmentmodell (z. B. ein Visual FoxPro-Automatisierungsserver) kann nur von einem Thread betreten werden, nämlich von dem Thread, der das Objekt erstellt hat. Allerdings kann ein Objektserver (wie etwa Microsoft Transaction Server) mehrere Objekte unterstützen, von denen jedes gleichzeitig von mehreren Threads betreten werden kann. Gewöhnliche, vom Objektserver gehaltene Daten müssen vor Threadkollisionen geschützt werden.

Das Apartmentmodell-Threading bietet die folgenden Vorteile:

• Alle Objekte, die ein Client in einem bestimmten Thread erstellt, werden in demselben Apartment (Thread) in der DLL erstellt. Für Aufrufe dieser Objekte, die in demselben Thread erfolgen, ist kein threadübergreifendes Marshalling erforderlich, wodurch die Effizienz der Aufrufe gesteigert wird.
• Da der Zugriff auf ein Objekt nur in dem Thread erfolgt, in dem es erstellt wurde, werden Aufrufe serialisiert, so dass ein Aufruf nie von einem Aufruf aus einem anderen Thread unterbrochen wird.
• Argumente für threadübergreifende Aufrufe werden gemarshallt, und der aufrufende Thread wird blockiert. Durch diese Synchronisierung von Daten wird der Status des aufrufenden Threads geschützt.

Apartmentthread-DLLs können keine eigenen Threads erstellen. Sobald ein Clientthread das erste Mal ein Objekt anfordert, das von der DLL bereitgestellt wird, wird ein neues Apartment erstellt, und für das Apartment wird das Init-Ereignis des Objekts ausgeführt. Alle Singlethread-Clientobjekte, die von diesem Client angefordert werden, befinden sich in demselben Apartment und greifen auf dieselben globalen Daten zu. Alle als PRIVATE deklarierten Objekte (einschließlich Formulare), die von den öffentlichen Objekten erstellt werden, befinden sich ebenfalls in dem Apartment.

Obwohl Visual FoxPro kein Verfahren bietet, durch das Apartments der Zugriff auf andere Apartments ermöglicht wird, kann ein Multithreadclient einen Verweis auf eine Objekt in Thread A erhalten und diesen Verweis an ein Objekt in Thread B übergeben.

Weitere Informationen zum Apartmentmodell-Threading erhalten Sie, indem Sie in der MDSN Library nach "Apartment-Model Threading" suchen.

Die Visual FoxPro-Implementierung des Apartmentmodell-Threadings beseitigt Konflikte beim Zugriff auf globale Daten von mehreren Threads aus, in dem jedes Apartment eine eigene Kopie der globalen Daten erhält. Das bedeutet, dass sich alle in diesem Thread erstellten Objekte in diesem Apartment befinden und nichts von der Existenz von Objekten in anderen Apartments wissen.

Visual FoxPro verwendet lokalen Threadspeicher, um einen eindeutigen Satz von globalen Anwendungs- und Umgebungsdaten für jeden Thread (jedes Apartment) zu speichern. Das bedeutet, dass zwei Instanzen derselben Klasse, die in unterschiedlichen Threads erstellt werden, nicht auf die Daten der jeweils anderen Instanz zugreifen können. Wenn sich diese beiden Instanzen jedoch in demselben Thread befinden, kann jedes Objekt auf die Daten des jeweils anderen Objekts zugreifen. Dies kann zu Zeitabstimmungsproblemen in einer Anwendung führen. Solange zwei Objekte in demselben Thread aus OLEPUBLIC-Klassen in demselben DLL-Server erstellt werden, verhält es sich faktisch so, dass Daten dieser Objekte beiden Objekten gemeinsam sind. (Anmerkung: Mit Hilfe der Session-Klasse können Sie jedem Objekt eine eigene private Datensitzung zuweisen.)

Ergänzend zum lokalen Threadspeicher stellt Visual FoxPro zudem für jedes Projekt (DLL) einen eindeutigen Satz globaler Daten bereit. Objekte, die aus unterschiedlichen Projekten (DLL-Servern) erstellt werden, können nicht auf die globalen Daten der anderen Objekte zugreifen, und zwar auch dann nicht, wenn sich die beiden Objekte in demselben Thread befinden.

Siehe auch

Auswahl von Prozesstypen | Auswahl einer Laufzeitbibliothek | Interoperabilität und das Internet | In Laufzeiten unterstützte Sprachen | Programmieranmerkungen zu Automatisierungsservern