Clients multithreads et handles de contexte

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

Tenez compte des points 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 certaines valeurs à partir de celui-ci). Ces appels n’ont pas besoin d’être sérialisés.

Pour ces situations, Windows XP offre 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 à plusieurs appels d’être distribués sur un handle de contexte unique. 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 de contexte s’exécute uniquement lorsque toutes les demandes clientes en attente sont terminées. Un appel à RpcScDontSerializeContext affecte l’ensemble du processus et n’est pas rétabli. L’utilisation de RpcScDontSerializeContext dans Windows XP et versions ultérieures n’est pas recommandée ; il rend le code serveur très compliqué lorsqu’il traite de manière fiable avec des conditions de concurrence inhérentes à des environnements complètement non sérialisés.