> Do you know of many cases where the disruptor pattern should be used by isn't?
The disruptor pattern is the way to solve any problem where you need to process events/transactions/commands/et. al. in a serialized fashion [0] as quickly as possible.
This problem space involves almost all business software, databases, simulations, etc.
I do not know of any other technique that would allow for faster serial processing of data, especially when controlling for practical applicability.
When I refer to blinders, I think I am mostly pointing to the ignorance regarding what is actually possible with the hardware (if you get the software out of its way). Any other technique involving cache-friendly structures, ring buffers, etc. is in the same league as far as I am concerned.
[0] To be as clear as possible, "serialized" in this context means that the consequences of event #1 may alter how event #2 would be processed, and so on.
The disruptor pattern is the way to solve any problem where you need to process events/transactions/commands/et. al. in a serialized fashion [0] as quickly as possible.
This problem space involves almost all business software, databases, simulations, etc.
I do not know of any other technique that would allow for faster serial processing of data, especially when controlling for practical applicability.
When I refer to blinders, I think I am mostly pointing to the ignorance regarding what is actually possible with the hardware (if you get the software out of its way). Any other technique involving cache-friendly structures, ring buffers, etc. is in the same league as far as I am concerned.
[0] To be as clear as possible, "serialized" in this context means that the consequences of event #1 may alter how event #2 would be processed, and so on.