Re: Tradeoffs between ConcurrentLinkingQueue and LinkedBlockingQueue

From:

Sebastian Millies <s#PUNKT#millies@ids#MINUS#scheer#KEIN-SPAM#.de>

Newsgroups:

comp.lang.java.programmer

Date:

Wed, 29 Sep 2010 10:28:23 +0200

Message-ID:

<i7v038$jdb$1@news2.dtag.de>

Am 29.09.2010 03:06, schrieb Kevin McMurtrie:

Forget polling. There's no way to guarantee a good tradeoff between
latency and CPU cost.

LinkedBlockingQueue and ArrayBlockingQueue may not be the best
performers. They use ReentrantLock, which currently performs worse than
a plain synchronized block. It's possible for a synchronized LinkedList
with wait()/notify() to perform better.

ConcurrentLinkedQueue is a top performer for multiple threads and it
never blocks. If you have a single dedicated thread calling poll(), you
can easily suspend and resume that one thread using LockSupport.
LockSupport's performance depends on the OS kernel.

[snip]

Thanks. Just to be sure, are you suggesting the following?

a) have a ConcurrentLinkedQueue:
         static Queue queue = new ConcurrentLinkedQueue<Request>();

b) Have a single consumer thread that is parked when the
    queue is empty:
         static Thread consumer = new Thread( new Runnable()
         {
             public void run()
             {
                 while( true ) {
                     Request req = queue.poll();
                     if( req != null ) {
                         doSomething( req );
                     }
                     else {
                         LockSupport.park();
                     }
                 }
             }
         } );

c) Have every producer thread unpark the consumer after gaving added
    an element to the queue:
       queue.offer( new Request() );
       LockSupport.unpark( consumer );

Additional question: From the javadoc, it wasn't entirely clear to me
what happens when a parked thread is interrupted?

-- Sebastian