Please search "Non-blocking algorithm" and you will find your solution and the reason for your original problem. OnQuoteUpdate should be a minimal function (no overhead; just handle the arrival of data). Move processing to another thread or application.
if you are streaming liquid tick data and your time frame are longer (minutes+), you are most certainly required to have exception handling in place to "throw" away the stale ticks (data loss) to catch up as needed. If the data gap becomes significant to the point of affecting the strategy calculation then support gets binged and system stops new position. Twisting a few words from my post out of context only makes you look like a douche.
Most strategies are not computationally-intensive enough to stretch modern computers unless they run on hundreds of symbols. If a strategy does lag behind during spikes of market activity, the best thing is to see if it's really necessary to run all the computations on every tick. Say, running complex optimisation every tick is just silly. On the other hand, there is a long history of commercial platforms implementing a quote queue that when it starts to lag during increased market activity it never catches up, even after a few minutes without ticks. Also note that the most likely reason for the next tick arriving before (even very simple) processing of the previous tick is finished is pooling of ticks in the network infrastructure. As a result, short sequences of ticks arrive effectively simultaneously. It has nothing to do with the OP's algorithm being a potential bottle neck. WhiteOut56, I understand the application that triggers "on tick" function calls is an "in-house" one. It probably already implements some kind of tick queuing. Is it possible to notify this application that the user's tick processing is "single-threaded" so that it doesn't make effort to deliver ticks in multiple threads? Can it be submitted as a feature request?