[concurrency-interest] Multi consumer queue

Brett Bernstein brett.bernstein at gmail.com
Tue Apr 7 00:06:49 EDT 2009


I could be entirely wrong on this, but to me it seems wasteful that I could 
have a program with 2 threads and 1 lock, do a bunch of locking and 
releasing over the course of the program, and as a result allocate millions 
of Nodes in the addWaiter method of AbstractQueuedSynchronizer.  It feels 
like there could be a much more efficient implementation here.  For example, 
if I wanted to build a low latency network application that never garbage 
collected it becomes much harder when the best locking tools allocate 
aggresively.
-Brett


----- Original Message ----- 
From: "Doug Lea" <dl at cs.oswego.edu>
To: "Brett Bernstein" <brett.bernstein at gmail.com>
Cc: <concurrency-interest at cs.oswego.edu>
Sent: Sunday, February 22, 2009 7:14 PM
Subject: Re: [concurrency-interest] Multi consumer queue


> Brett Bernstein wrote:
>> As a side note, I have a bit of a qualm with ReentrantLock.  Specifically 
>> the fact that waiting on the lock requires new to be called, which in 
>> some apps/situations I try to avoid.
>
> I assume you mean internal queue nodes constructed when threads block
> waiting for locks? Of course the same thing happens inside builtin locks,
> but uses the JVM's internal memory management, which in most JVMs does
> not have the benefit of sitting on a high-performance garbage collector.
>
> There are a bunch of situations in (concurrent) programming where
> allocating memory is a bad idea, but waiting for locks is not
> often among them. But if you would like to trade off more time
> spinning rather than  allocating and blocking, you can precede
> calls to lock() with some number of calls to tryLock.
>
> -Doug
> 



More information about the Concurrency-interest mailing list