Pull Request Test Coverage Report for Build 440

• 132 of 132 (100.0%) changed or added relevant lines in 2 files are covered.
• 21 unchanged lines in 4 files lost coverage.
• Overall coverage increased (+0.4%) to 68.973%

Totals
Change from base Build 437:	0.4%
Covered Lines:	5653
Relevant Lines:	8196

💛 - Coveralls

it is addressing #180

Looking forward to this. When is the next release scheduled?

Sorry for the slow response. Totally swamped ATM, will release around end of October.

@felixbarny I've implemented the batch methods assuming mostly single threaded usage to get the best of it: at the first failed attempt (due to contention) to fill/drain in batches it will just fill/drain one by one.
it is what you're expecting?

I'm using an MPMC queue as the basis for an object pool. My scenario is that I have multiple consumers and, under normal circumstances, a single producer. In rare cases, there can be multiple producers.

I was hoping that both the producer and the consumers would benefit from batch operations. The producer could batch up multiple objects and add them to the object pool/queue in batch. Also, the consumers could get multiple objects and buffer them thread-local. By doing this, my expectation would be to gain performance by reducing the amount of CAS operations (1 per batch vs 1 per element).

@felixbarny

My scenario is that I have multiple consumers and, under normal circumstances, a single producer. In rare cases, there can be multiple producers.

I would say for sure that it will do it for the producers, given the "mostly single-threaded" scenario, will benefit a lot by batch fill

By doing this, my expectation would be to gain performance by reducing the amount of CAS operations (1 per batch vs 1 per element).

That's the ratio behind this PR indeed :)
I just suggest to build up some benchmark/experiment with your scenarios to look if it is improving things as you expect and with different jctools.mpmc.max.lookahead.step parameters 👍