[concurrency-interest] ConcurrentLinkedQueue padding

Carl Mastrangelo notcarl at google.com
Wed Nov 22 14:03:17 EST 2017

Ah, I should have clarified, I was thinking of the MPSC/SPMC case.  I agree
it would take more memory, but in some cases it would be convenient to let
the user make that trade off.  The consumer would fight with the producers
if the queue was small.     Is the recommendation to use a more specific
class than the JDK ones, or do the JDK ones still usually win?

On Wed, Nov 22, 2017 at 8:06 AM, Martin Buchholz <martinrb at google.com>

> None of the linked list based node classes use @Contended.  Node classes
> tend to be small and @Contended adds a lot of memory overhead.  When
> multiple threads are enqueueing, you're likely instead to get "true
> sharing" contention as they all try to CAS the very same next link.
> On Tue, Nov 21, 2017 at 1:33 PM, Carl Mastrangelo via Concurrency-interest
> <concurrency-interest at cs.oswego.edu> wrote:
>> Hi concurrency interest,
>> I was looking through ConcurrentLinkedQueue and noticed that unlike
>> several of the other concurrent classes, the volatile Node pointers as well
>> as the Nodes themselves don't have any padding.  This makes me wonder,
>> could there be false sharing when using multiple producers to add to the
>> queue?  I was under the impression that the GC tends to group fields of a
>> class near each other, which would imply that there is going to likely be
>> contention when quickly updating (and reading) from it.
>> Carl
>> _______________________________________________
>> Concurrency-interest mailing list
>> Concurrency-interest at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/concurrency-interest
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cs.oswego.edu/pipermail/concurrency-interest/attachments/20171122/27786609/attachment.html>

More information about the Concurrency-interest mailing list