Clients multithreads et handles de contexte

Lorsque vous avez un client multithread où plusieurs threads utilisent le même handle de contexte instance, l’accès au handle de contexte instance est sérialisé sur le serveur par défaut. Cela évite au gestionnaire de serveur d’avoir à se protéger contre un autre thread du même client qui modifie le contexte ou le contexte en cours d’exécution lors de la distribution d’un appel. Toutefois, dans certains cas, la sérialisation peut avoir un impact sur les performances.

Considérez les éléments suivants : deux threads clients appellent un appel de procédure distante qui ne modifie pas l’état du contexte (par exemple, l’appel obtient simplement des valeurs à partir de celui-ci). Ces appels n’ont pas besoin d’être sérialisés.

Pour de telles situations, Windows XP propose un modèle de sérialisation en mode mixte, où chaque méthode peut être déclarée avoir un accès exclusif ou partagé à un handle de contexte. Pour plus d’informations, consultez context_handle_serialize et context_handle_noserialize .

Dans les versions de Windows antérieures à Windows XP, le seul moyen d’autoriser l’accès simultané à un handle de contexte consiste à appeler la fonction RpcSsDontSerializeContext pour permettre la distribution de plusieurs appels sur un seul handle de contexte. L’appel de la fonction RpcSsDontSerializeContext ne désactive pas entièrement la sérialisation ; lorsqu’une exécution de contexte se produit, la routine d’exécution du contexte s’exécute uniquement lorsque toutes les demandes clientes en suspens sont terminées. Un appel à RpcScDontSerializeContext affecte l’ensemble du processus et n’est pas réversible. L’utilisation de RpcScDontSerializeContext dans Windows XP et versions ultérieures n’est pas recommandée ; il rend le code serveur très compliqué quand il traite de manière fiable des conditions de concurrence inhérentes dans des environnements complètement non sérialisés.