 <p>IMHO, single producer accessed by multi threads with lock won't resolve your problem, because it simply shift the locking from the disruptor side to your own program.</p> <p>The solution to your problem varies from the type of event model you need. I.e. do you need the events to be consumed chronologically; merged; or any special requirement. Since you are dealing with disruptor and multi producers, that sounds to me very much like FX trading systems :-) Anyway, based on my experience, assuming you need chronological order per producer but don't care about mixing events between producers, I would recommend you to do a queue merging thread. The structure is</p> <ul> <li>Each producer produces data and put them into its own named queue</li> <li>A worker thread constantly examine the queues. For each queue it remove one or several items and put it to the single producer of your single producer disruptor.</li> </ul> <p>Note that in the above scenario,</p> <ul> <li>Each producer queue is a single producer single consumer queue.</li> <li>The disruptor is a single producer multi consumer disruptor.</li> <li>Depends on your need, to avoid a forever running thread, if the thread examine for, say, 100 runs and all queues are empty, it can set some variable and go wait() and the event producers can yield() it when seeing it's waiting.</li> </ul> <p>I think this resolve your problem. If not please post your need of event processing pattern and let's see.</p>