Clients multithread et handles de contexte
Quand vous avez 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é par défaut sur le serveur. Cela évite au gestionnaire de serveur d’avoir à se prémunir contre un autre thread du même client en modifiant le contexte ou le contexte qui s’est exécuté pendant 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). De tels appels n’ont pas besoin d’être sérialisés.
dans ce cas, Windows XP offre un modèle de sérialisation en mode mixte, où chaque méthode peut être déclarée comme disposant d’un accès exclusif ou partagé à un handle de contexte. Pour plus d’informations, consultez _ _ sérialisation de handle de contexte et handle de contexte _ _ 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 de contexte s’exécute uniquement lorsque toutes les demandes de client 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 les versions ultérieures n’est pas recommandée. Cela rend le code du serveur très compliqué lorsqu’il s’agit d’une gestion fiable des conditions de concurrence inhérentes à des environnements totalement non sérialisés.