Event consumption for concurrency in a multicore application

[junkclark]

Hi all,

Thanks in advance

How would you go about the following.

Target machine 4 core AMD

I have an event that is raised my the main thread of the application.

The event is consumed by several different classes in the application. I want them all to run concurrently up to the max cores available and then que the rest in order.

The work routine in each class is relatively small but concurrency is the goal.

Considering this.

A. Create a background worker on each classes initialization and have the event handler start the worker.

B. Create a delegate to the do-work sub that is called by the event handler

A- Pros - worker is only created once and reusable so only pay creation cost once.
A-Cons could create a ton of workers that consume resources eventually.

B- Pros Smaller thread pool
B- Cons Lot of overhead

I am 100% open for a better idea.

Thanks

 

[jmcilhinney]

I don't think what you're asking for is really practical. I would suggest that you simply use the ThreadPool and let the system worry about the optimum number of threads based on system configuration and current load. In each event handler call ThreadPool.QueueUserWorkItem and then let the system worry about scheduling.

 

[junkclark]

simple is better

Thats what happens when you do these things at night. I agree completely. 1 line of code and near concurrency.

Thanks