#511·disruptor

Potential inconsistency in MultiProducerSequencer.remainingCapacity(): cursor read twice

Author: NYgometsCreated Apr 30, 2026Updated Sep 13, 2026

Potential inconsistency in MultiProducerSequencer.remainingCapacity()

Description

MultiProducerSequencer.remainingCapacity() reads cursor twice, whereas SingleProducerSequencer.remainingCapacity() reads it only once.

Current behavior

MultiProducerSequencer (reads cursor twice):

java
long consumed = Util.getMinimumSequence(gatingSequences, cursor.get()); // first read
long produced = cursor.get();                                            // second read
return getBufferSize() - (produced - consumed);

SingleProducerSequencer (reads cursor once):

java
long nextValue = this.nextValue;
long consumed = Util.getMinimumSequence(gatingSequences, nextValue);
long produced = nextValue;
return getBufferSize() - (produced - consumed);

Question

Is the double read of cursor.get() in MultiProducerSequencer.remainingCapacity() intentional?

Since cursor is read at two different points in time, produced may reflect a more recent value than the one used to calculate consumed. This means the two values are not based on the same snapshot, which could lead to a less accurate result.

If this is not intentional, aligning it with SingleProducerSequencer by reading cursor once would improve consistency and avoid an unnecessary volatile read:

java
long produced = cursor.get();
long consumed = Util.getMinimumSequence(gatingSequences, produced);
return getBufferSize() - (produced - consumed);

Note

I understand that remainingCapacity() cannot guarantee a precise snapshot in a multi-producer environment. The question is purely about whether the inconsistency between the two implementations is intentional or an oversight.