[concurrency-interest] Method on LinkedBlockingQueue throws IllegalStateException

Joe Bowbeer joe.bowbeer at gmail.com
Tue Apr 17 19:10:36 EDT 2007

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?


I think you may be confused by some of the history here.
Non-thread-safe collections came first and then concurrent collections
came later and were layered on top of collections.

You can argue that this layering was not done perfectly (wasn't it?),
but given that things are the way they are, namely that BlockingQueue
extends Queue extends Collection, it doesn't make sense to advocate
the removal of a Collection method from AbstractQueue -- or one of the
blocking queues that extend it.


On 4/17/07, Szabolcs Ferenczi <szabolcs.ferenczi at gmail.com> wrote:
> On 17/04/07, Joe Bowbeer <joe.bowbeer at gmail.com> wrote:
> > Look at the documentation for Queue.
> >
> > In particular, the distinction between 'add' and 'offer':
> >
> > http://java.sun.com/javase/6/docs/api/java/util/Queue.html
> Well, I did have a look at it. That is why I made my point. What is
> your point? Did you think about it?
> Your reference is to an interface definition for a sequential data
> structure. I called your attention, well it seems you are not
> listening, that there is a big difference between operations on a
> sequential data structure and a shared data structure. By sequential
> data structure I mean one that is designed to be used in a single
> threaded environment.
> I am talking about method `add' and not about method `offer.' Do you
> think it is a correct behavior throwing an exception if a shared data
> structure is not in the expected state?
> Besides, method `offer' also smells in multi-threaded environment. But
> it at least returns false in case the state is not as expected.
> Best Regards,
> Szabolcs

More information about the Concurrency-interest mailing list