Un abonné d'événement .NET unique associé à plusieurs éditeurs d'événements et multithread

Question

Supposons que je possède une classe unique, contenant une méthode simple. Disons qu'il y a un délégué avec la même signature que cette méthode.

Je souhaite exécuter plusieurs processus de longue durée, chacun lancé à partir de cette classe. Chaque processus contient un événement, composé de délégués de multidiffusion du même type que le délégué mentionné ci-dessus. Une fois que chaque classe "worker" est instanciée, la classe "controlling", mentionnée ci-dessus, souscrit à l'événement du worker, avec la même méthode simple mentionnée ci-dessus. Une fois que le travail de chaque travailleur est terminé, son événement est appelé.

Dans un environnement monothread, cette architecture est assez simple. Cependant, je prévois d'exécuter chaque processus de travail sur un thread séparé. Par conséquent, plusieurs travailleurs invoqueront leurs événements (presque) simultanément, chacun souscrit par la méthode simple de la classe contrôlante.

Y at-il une garantie, étant donné que les délégués sont immuables, que chaque thread aura un accès exclusif à la méthode simple? Je ne suis pas concerné par le code de verrouillage dans la méthode simple, je suis inquiet que Thread # 1 invoquera la méthode avec un ensemble de paramètres, et Thread # 2 invoque la même méthode, presque en même temps. Avant que le thread n ° 1 entre dans l'instruction lock, le thread n ° 2 (qui entre dans la méthode presque au même moment que le thread n ° 2) remplace les paramètres spécifiés par Thread n ° 1, ce qui entraîne le traitement effectif des paramètres du thread n ° 2 deux fois? Je me rends compte que c'est un peu une bouchée, je serais ravi de fournir plus d'informations.

Answer 1

On dirait que vous êtes le candidat idéal pour le cadre réactif. (RX)

http://codebetter.com/blogs/matthew.podwysocki/archive/2009/10/14/introducing-the-reactive-framework-part-i.aspx

Je suis encore en train d'envelopper ma tête, mais ce scénario est en plein sweetspot pour cette nouvelle technologie.

Answer 2

Les threads ne peuvent pas remplacer les paramètres des méthodes - ceux-ci sont stockés sur la pile et sont toujours thread-safe. La seule chose qui pourrait ne pas être thread safe dans votre cas est l'état de votre classe.

Answer 3

Merci à vous deux pour vos réponses.

@Grzenio: Si ce thread ne peut pas remplacer les paramètres de la méthode, ce que cela signifie que les déclarations de verrouillage ne sont pas nécessaires dans la méthode elle-même, à savoir, la méthode est thread-safe efficace:

private void DoSomething(object someObject, object someOtherObject) { 
    lock(someVariable) { 

    // Does this code need to be locked, or is the method thread-safe? 
    // Surely 2 threads accessing this method could result in a race condition? 

    } 
} 

@ Tim: Merci Je vais regarder ça.