[concurrency-interest] Single producer, single consumer: unexpected delays for producer

David Holmes dcholmes at optusnet.com.au
Sun Aug 10 18:46:08 EDT 2008


Hi Doug,

But in this case removing the network load in the consumer causes the
consumer to execute take() more rapidly and so it is more likely to find the
queue empty, and so block. But this is the case that appears 6x faster. ???

David

> -----Original Message-----
> From: concurrency-interest-bounces at cs.oswego.edu
> [mailto:concurrency-interest-bounces at cs.oswego.edu]On Behalf Of Doug Lea
> Sent: Sunday, 10 August 2008 1:16 AM
> To: Daniel Harvey
> Cc: concurrency-interest at cs.oswego.edu
> Subject: Re: [concurrency-interest] Single producer, single consumer:
> unexpected delays for producer
>
>
> Daniel Harvey wrote:
> >
> > What is so odd to me is that 90% of the total time spent in onMessage()
> > comes from time spent in queue.offer() despite the fact that this is
> > only called for 20% of the messages. If I have the sendThread skip the
> > socketChannel.write() command, than the situation changes greatly: time
> > spent in queue.offer drops by a literally a factor of 6 or so.
> >
>
> This may be due to slow thread unblocking in your VM.
> You can try to avoid this a bit by pre-spinning on take:
>
> String prespinTake(BlockingQueue<String> q) {
>    for (int i = 0; i < SPINS; ++i) {
>      String x = q.poll();
>      if (x != null)
>         return x;
>    }
>    return q.take();
> }
>
> where SPINS is a number say between 1 and 1000.
> This will avoid offer() needing to wake up a blocked take thread.
>
> -Doug
> _______________________________________________
> Concurrency-interest mailing list
> Concurrency-interest at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/concurrency-interest



More information about the Concurrency-interest mailing list