[concurrency-interest] Is LinkedBlockingQueue.isEmpty() thread safe?

Szabolcs Ferenczi szabolcs.ferenczi at gmail.com
Fri Apr 20 15:18:54 EDT 2007


On 20/04/07, Holger Hoffstätte <holger at wizards.de> wrote:
> Szabolcs Ferenczi wrote:
> > I was wondering whether it was planned to be used in a multi-threading
> > environment. Now, although it is thread safe in the sense that it does
> > not brake anything in the shared data structure, it is a useless
> > method for a data structure that is designed to be used by concurrent
>
> No, it is not. Since Java does not allow one to actually remove methods in
> subclasses, the only way is to let the user determine on whether the
> method makes sense in a certain context.

You do not have to remove it. There can be other techniques. But first
of all, a shared class should not be derived from a sequential one.
They are simply not compatible just because of the basic and
fundamental difference between the sequential and the concurrent
environment. The isEmpty() method illustrates it well enough.

> Should a concurrent class'
> isEmpty() throw MightBeStaleStateException instead?

If you think it should throw any exception, it is even worse. I am
afraid, it is a very amateur idea in a concurrent environment. The
isEmpty() query is useless, as I have explained earlier. The result of
the query does not tell you anything whatsoever in a concurrent
environment. But throwing an exception, well, that is itself an
exceptionally wrong idea.

I doubt if this query could be used in a concurrent program at all. I
wonder if anyone can show a meaningful application of it. It is a mere
YAGNI. I am afraid, the presence of the isEmpty() call and some other
query method calls on a shared data structure indicate some
incompetence in concurrent programming. It is a bad smell in a
concurrent program, as they would call it in the refactoring arena.

Best Regards,
Szabolcs



More information about the Concurrency-interest mailing list