I'm working with a market data feed API in VB.NET. API is written is written in C#.
This API calls a method in one of my classes to signal when an event such as a price tick or a trade arrives on a TCP socket. This can happen upwards of 10,000 times per second. After the event comes in, the data is converted from a byte stream into data structures and the data structures are used in a pricing model.
Each event can take a couple ms to process, so multi-threading is probably necessary. If events are not processed in time, they queue up, but this is extremely undesirable, so we want to process events without them backing up.
I wanted to gather your thoughts on the do's and don't of processing this many events. For example, should I use the ThreadPool.QueueWorkItem or should I build my own threadpool?
Has anyone used ThreadPool.QueueWorkItem for so many small work items?
If I build my own threadpool, the approach that makes sense is to create a wrapper for the thread, and suspend the thread. When an event arrives, put the data into the wrapper and call resume() to make the thread process the event. Once the processing is complete, do another suspend() because once a thread dies, it cannot be restarted.
If I build my own threadpool, what is the overhead of doing suspend/resume so frequently? What have been your experiences with having many threads going on and off at the same time?
Thanks in advance