[concurrency-interest] Method on LinkedBlockingQueue throws IllegalStateException
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?
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
> 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".
So much about history and the restrictions by it. It is called
"engineering", isn't it? Hic Rhodus, hic salta.
More information about the Concurrency-interest