the Disruptor framework vs The Complexities of Concurrency

[Nick B]

On Thursday, 13 December 2012 at 16:07:13 UTC, Dmitry Olshansky 
wrote:
> 12/13/2012 4:59 AM, David Piepgrass пишет:
>>> Maybe, but I'm still not clear what are the differences 
>>> between a
>>> normal ring buffer (not a new concept) and this "disruptor" 
>>> pattern..
>>
>> Key differences with a typical lock-free queue:
>
> But for start I'd define it is a framework for concurrent 
> processing of a stream of tasks/requests/items on a well 
> structured multi-staged pipeline.
> 
   An excellent one sentence description!

>> [snip]

> There is also highly flexible (policy-based design) selection 
> of how consumers wait on data:
> - either busy _spin_ on it thus getting the highest 
> responsiveness at the cost of wasted CPU cycles
> - lazy spin (that yields) no outright burning of CPU resources 
> but higher latency
> - and even locking with wait-notify that saves greatly on CPU 
> but kills responsiveness and throughput (but gives freedom to 
> spend CPU elsewhere)
>
> Thanks for pointing this out.

[snip]
>
> Another important IMHO observation is that the order of 
> processed items is preserved* and this is interesting property 
> if you consider doing the same stages as lock-free queues with 
> a pool of consumers at each stage. Things will get O-o-O very 
> quickly.


what does O-o-O mean ? >

Nick