[concurrency-interest] j.u.c/backport performance on Windows
szabolcs.ferenczi at gmail.com
Sun Apr 1 18:51:47 EDT 2007
On 01/04/07, Peter Kovacs <peter.kovacs.1.0rc at gmail.com> wrote:
> I haven't tried it, because I got worried about Doug Lea's comment
> that it may be less scalable that LinkedBlockingQueue. I will probably
> try it anyway.
I do not know what he means exactly but the thing is that the
LinkedBlockingQueue is carefully designed and behaves well against
large number of concurrent users. You can implement the same
functionality based on the combination of e.g. ConcurrentLinkedQueue
and semaphores or condition variables. But most probably that will not
be as efficient as the LinkedBlockingQueue. Note that Hanson's
ConcurrentLinkedBlockingQueue performs good as well, in fact, I think,
it performs slightly better than the LinkedBlockingQueue.
> In more concrete terms: you can find the problematic backport-based
> implementation here:
> . "outputQueue" is the variable where I am using LinkedBlockingQueue.
> And yes, my case falls into the multiple-producer-one-consumer
Now I can see you are using LinkedBlockingQueue. That is good enough.
The strange thing I can see there in the code is the extra lock
inputProducerLock. Can you explain the role of that lock? It might
serialize producers more than necessary. It is a guess only, and if
you try to explain the role of it, it can turn out whether it is a
good guess or not.
The other strange thing I can see there is that the producer waits
when the queue is full and starts producing the next item only after
the queue has a place. I think the producers could normally create an
item and then try to insert it into the queue.
These are the two issues I can see right now. I hope it helps. I am
not sure these issues can explain the performance differences on the
different platforms, though.
More information about the Concurrency-interest