Dois-je verrouiller l'accès aux membres de l'instance?
Exemple: P>
public class HttpModule : IHttpModule { //... Dictionary<int, int> foo; void UseFoo(int a, int b) { foo[a] = b; } }
4 Réponses :
Ce n'est pas cristal clair pour moi jusqu'à présent de la documentation MSDN, mais j'ai trouvé un Poste du forum de quelqu'un qui prétend connaître la réponse . On dirait que vous ne devriez pas vous attendre à Bad Stuff em> pour arriver avec votre implémentation, mais vous devez savoir que l'état code> FOO code> ne sera pas nécessairement partagé à tous les résultats depuis que votre httpmodule code> sera créé une fois par
httpApplication code> que IIS choisit de rester dans sa piscine. P>
Oui, il réutilise l'instance parmi de nombreuses demandes différentes. Mais la question est de savoir si elle réduit l'instance entre différents threads.
D'après ce que je peux dire: Oui, mais pas en même temps. Un httpApplication semble être attribué à une demande donnée pendant la durée de cette demande.
D'accord merci. J'attendrai que quelqu'un comment le sait exactement cela, car je vais utiliser ce code dans l'environnement de production, et je serai difficile à déboguer.
J'ai récemment trouvé un article qui touche légèrement sur cette question: http://www.dominicpettifer.co.uk/blog/41/ihttpmodule-gotchas---the-init--method-can-get-called-multiple-times
Cela ne 'T mentionne les threads, mais dit seulement que le processus ouvrier sera P>
Instanciez autant de nombreux httpApplication objets comme il pense qu'il a besoin, alors Ça va les ponder pour la performance raisons, réutiliser des instances comme neuves Les demandes entrent avant de les envoyer retour dans la piscine. P> blockQquote>
Suivre le code dans le lien, vous pouvez être sûr que votre code init est exécuté une fois de manière filaire: p>
xxx pré> i ' VE Vous avez eu le sens de configurer une application de test pour l'exécuter et de le tester, juste pour voir si c'est vrai, mais je n'ai pas eu le temps. P> P>
Merci pour votre réponse. Cela vérifie si cela est partagé maintenant. J'ai besoin de le savoir exactement, car comme je me suis dit ci-dessus, je l'utiliserai dans l'environnement de la production et que ce sera vraiment douloureux si cela est modifié, par exemple pendant une mise à jour de .NET Framework ou IIS.
L'article posté par Jim est intéressant, mais comme Jim dit qu'il ne mentionne rien de la sécurité du fil. P>
Je suppose que vous n'auriez besoin que du mécanisme de verrouillage si vous initialisez les membres statiques ou effectuez des initialisations «une seule fois», c'est-à-dire initialiser une ressource statique. P>
Je ne pouvais pas conclure de MSDN ni l'article mentionné par Jim que nous avons besoin du mécanisme de verrouillage lors de l'initialisation des variables de classe non statiques. P>
Je voulais offrir ici mes résultats liés à cette question comme je l'ai observé dans IIS6: p>
J'ai beaucoup abordé de manière approfondie dans IIS6 et j'ai trouvé des résultats intéressants en utilisant Log4Net et la réflexion pour capturer l'historique d'exécution. Ce que j'ai trouvé, c'est qu'il y a une "gestion de thread" étendue dans les coulisses. Il semble qu'il existe une série de threads «primaire» correspondant à 1: 1 à Alors qu'une réponse, je dirais que Ce numéro me troublait depuis quelque temps, j'espère que cette information aide quelqu'un. P> httpApplication code>. Ces threads ne manipulent pas exclusivement le pipeline pour votre demande. Divers sous-threades différents
httpmodules code> est strong> partagé entre les threads. En termes de valeurs d'instance de verrouillage, ceci serait applicable si les valeurs s'appliquaient à toutes les demandes qui utilisent le module et doivent maintenir un État. Je pouvais voir que cela était utile s'il tente de maintenir des valeurs d'instance d'état coûteux de déterminer afin de pouvoir être réutilisés dans des demandes suivantes. P>