# Concurrent Sequencing

DevFeed: [Concurrent Sequencing](<https://devfeed.tech/articles/concurrent-sequencing-30639.md>)

Original publisher: [Read original article](<http://bad-concurrency.blogspot.com/2011/12/concurrent-sequencing_31.html>)

Author: Michael Barker (noreply@blogger.com)

Published: 2011-12-31T10:37:00Z

Content type: article

Language: en

Sources: [Bad Concurrency](<https://devfeed.tech/sources/bad-concurrency.md>)

Topics: [Concurrency](<https://devfeed.tech/topics/concurrency.md>), [Concurrent Programming](<https://devfeed.tech/topics/concurrent-programming.md>), [Java](<https://devfeed.tech/topics/java.md>), [cpu](<https://devfeed.tech/topics/cpu.md>)

Tags: [concurrent](<https://devfeed.tech/tags/concurrent.md>), [cpu](<https://devfeed.tech/tags/cpu.md>), [event](<https://devfeed.tech/tags/event.md>), [java](<https://devfeed.tech/tags/java.md>), [process](<https://devfeed.tech/tags/process.md>), [processors](<https://devfeed.tech/tags/processors.md>), [sequences](<https://devfeed.tech/tags/sequences.md>)

## AI overview

The article examines poor Disruptor performance under heavy contention when there are fewer available processor cores than busy threads. It attributes the problem to a busy-spin publishing loop that can starve the thread updating the cursor, and discusses Java and processor-level constraints affecting possible solutions.

## Source excerpt

A few weeks ago one of the users of the Disruptor posted some worrying benchmarks: ThreePublisherToOneProcessorSequencedThroughputTest run 0: BlockingQueue=645,161 Disruptor=1,772 ops/sec run 1: BlockingQueue=1,250,000 Disruptor=20,000,000 ops/sec run 2: BlockingQueue=1,250,000 Disruptor=56 ops/sec It appears under heavy contention with fewer available cores than busy threads the Disruptor can perform terribly. After a bit of investigation I managed to isolate the problem. One of the most complex parts of the Disruptor is the multi-threaded claim strategy. It is the only place in the Disruptor where - out of necessity - we break the single-writer principal. The approach that we used was very simple. Each thread claims a slot in the ring buffer using AtomicLong.incrementAndGet(). This ensures that each claim will return a unique sequential value. The complexity arrives when the multiple threads try to publish their sequence. We require that all events placed in the ring buffer must be made available to event processors in a strictly sequential order. To ensure this behaviour we have a method called serialisePublishing(). Our simple implementation would have the thread that is publishing busy spin until the last published sequence (the cursor) is one less the value being published. This works because each sequence published is unique and strictly ascending. For example if one thread wants to publish the value 8, it will spin until the cursor value reaches 7. Because no other thread will be trying publish value 8 it can make progress and ensuring the sequential publishing behaviour in the process. However, this busy spin loop causes problems when there are more threads than cores. The threads that need wait for the prior sequences to be published can starve out the thread that should be updating the cursor. This leads to the unpredictable results shown above. We need a better solution. In an ideal world there would be a Java API that would compile down to the Intel MON