Multithreadclients und Kontexthandles

Wenn Sie über einen Multithreadclient verfügen, für den mehrere Threads dasselbe Kontexthandle instance verwenden, wird der Zugriff auf das Kontexthandle instance standardmäßig auf dem Server serialisiert. Dies erspart dem Server-Manager, dass er sich vor einem anderen Thread aus demselben Client schützen muss, der den Kontext oder den Kontext ändert, der während eines Aufrufs ausfällt. In bestimmten Fällen kann sich die Serialisierung jedoch auf die Leistung auswirken.

Betrachten Sie Folgendes: Zwei Clientthreads rufen einen Remoteprozeduraufruf auf, der den Zustand des Kontexts nicht ändert (z. B. ruft der Aufruf einfach einige Werte daraus ab). Solche Aufrufe müssen nicht serialisiert werden.

Für solche Situationen bietet Windows XP ein Serialisierungsmodell im gemischten Modus, bei dem jede Methode als exklusiven oder freigegebenen Zugriff auf ein Kontexthandle deklariert werden kann. Weitere Informationen finden Sie unter context_handle_serialize und context_handle_noserialize .

In Windows-Versionen vor Windows XP besteht die einzige Möglichkeit zum Zulassen des gleichzeitigen Zugriffs auf ein Kontexthandle darin, die RpcSsDontSerializeContext-Funktion aufzurufen, um das Senden mehrerer Aufrufe für ein einzelnes Kontexthandle zu ermöglichen. Beim Aufrufen der RpcSsDontSerializeContext-Funktion wird die Serialisierung nicht vollständig deaktiviert. wenn ein Kontext-Rundown auftritt, wird die Kontextausführungsroutine nur ausgeführt, wenn alle ausstehenden Clientanforderungen abgeschlossen sind. Ein Aufruf von RpcScDontSerializeContext wirkt sich auf den gesamten Prozess aus und ist nicht revertierbar. Die Verwendung von RpcScDontSerializeContext in Windows XP und höheren Versionen wird nicht empfohlen. Es macht Servercode sehr kompliziert, wenn er zuverlässig mit Racebedingungen umzugehen, die in vollständig nicht serialisierten Umgebungen inhärent sind.