A Single .NET Event Subscriber Associated with Multiple Event Publishers & Multithreading

Question

Hello,

Supposing I have a single class, containing a simple method. Let's say that there is a delegate with the same signature as this method.

I want to run multiple long-running processes, each one launched from this class. Each process contains an event, which is composed of multicast delegates of the same type as the delegate mentioned above. Once each "worker" class is instantiated, the "controlling" class, mentioned above, subscribes to the worker's event, with the same simple method mentioned above. Once each worker's job is complete, it's event is invoked.

In a single-threaded environment, this architecture is fairly straight-forward. However, I plan to run each worker process on a separate thread. Therefore, multiple worker's will invoke their events (almost) simultaneously, each one subscribed to by the controlling class's simple method.

Is there a guarantee, given that delegates are immutable, that each thread will have exclusive access to the simple method? I'm not concerned about locking code within the simple method, I'm concerned that Thread #1 will invoke the method with a set of parameters, and Thread #2 invokes the same method, at almost the same time.

Before Thread#1 enters the lock statement, can Thread #2 (which enters the method at almost the same time as Thread #2) overwrite the parameters specified by Thread #1, resulting in Thread #2's parameters effectively being processed twice?

I realise that this is a bit of a mouthful, I'd be delighted to provide more info.

Answer 1

Sounds like you are the perfect candidate for the Reactive Framework. (RX)

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

I'm still trying to wrap my head around it, but this scenario is right in the sweetspot for this new tech.

Answer 2

Threads can't override parameters to methods - these are stored on the stack and are always thread safe. The only thing which might not be thread safe in your case is the state of your class.

Answer 3

Thank you both for your replies.

@Grzenio: If thread's can't overwrite method parameters, does this mean that lock statements are unnecessary within the method itself, i.e., the method is effectively thread-safe:

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: Thanks, I'll look into this.