However, if you handle it by the obvious choice of mutex locking, we're back to the same scenario - the first thread is still processing your event, and the next seven threads also end up waiting for the same lock, resulting in the entire pool being frozen. Depending on how the thread pool is configured, it might or might not fire up more threads if all of the threads are waiting, but even if it does, all of the subsequent threads it fires up will near-immediately wind up holding for the same lock.
That is why I asked NT how they expected, as a best practice, for contention to be handled, and whether we should do the locking ourselves, or how they recommended that it be done. It seems to me this that for those cases where the ticks (or depth events, or whatever) must be handled (fully) in order, locks may be a requirement so it puzzles me that we may be not recommended to go that route. The only alternative I can quickly foresee is that they handle it on the platform side (by only sending the events one at a time to a given indicator, waiting until the first one exits before sending the next one) but that is not the way it is working so far, and it adds complexity for them.
Comment