[concurrency-interest] Method on LinkedBlockingQueue throws IllegalStateException

Szabolcs Ferenczi szabolcs.ferenczi at gmail.com
Tue Apr 17 19:54:48 EDT 2007

On 18/04/07, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> I guess I didn't understand your question.  AbstractQueue implements
> Queue, right?
> Have you looked at the BlockingQueue definition, and the 'put' and
> 'take' methods that it provides for concurrent access?
> http://java.sun.com/javase/6/docs/api/java/util/concurrent/BlockingQueue.html

Of course I have had a look at it (you strange guys keep asking it)
and yes, I am afraid, you really did not understand the point. That is
correct of you. I do not speak about the `put' and `take' methods,
which I think are quite appropriate for a shared queue. I am talking
about the inappropriate `put' and `remove' methods, which throw
exceptions when the operation cannot be carried out on the shared data
structure at the moment. I must ask again: Why do you think it is a
good idea to throw an exception if you are going to add a piece of
data to a shared data structure but there is no room for it at the
very moment?

> I think you may be confused by some of the history here.

No, I am not. Well, I am not concerned about history in this respect.
Your partner just explained to me that it is a kind of "engineering".
He does not want to think in advance and he claims that he simply
engineers the problem when needed. Well, I pointed the problem out for

Note: "If it turns out that lock-free doesn't work as well on future
architectures then we'll replace it with something else as needs be.
That's how the real world works: there's a need, then a solution, and
if the need changes or the solution stops working, we adapt and come
up with a new solution. It's called "engineering".

David Holmes"

So much about history and the restrictions by it. It is called
"engineering", isn't it? Hic Rhodus, hic salta.

Best Regards,

More information about the Concurrency-interest mailing list