Question

Documentation of BlockingQueue says bulk operations are not thread-safe, though it doesn’t explicitly mention the method drainTo().

BlockingQueue implementations are
thread-safe. All queuing methods
achieve their effects atomically using
internal locks or other forms of
concurrency control. However, the bulk
Collection operations addAll,
containsAll, retainAll and removeAll
are not necessarily performed
atomically unless specified otherwise
in an implementation. So it is
possible, for example, for addAll(c)
to fail (throwing an exception) after
adding only some of the elements in c.

Documentation of drainTo() method specifies that the collection, to which the elements of BlockingQueue are drained to, cannot be modified in thread-safe fashion. But, it doesn’t mention anything about drainTo() operation being thread-safe.

Removes all available elements from
this queue and adds them to the given
collection. This operation may be more
efficient than repeatedly polling this
queue. A failure encountered while
attempting to add elements to
collection c may result in elements
being in neither, either or both
collections when the associated
exception is thrown. Attempts to drain
a queue to itself result in
IllegalArgumentException. Further, the
behavior of this operation is
undefined if the specified collection
is modified while the operation is in
progress.

So, is drainTo() method thread-safe? In other words, if one thread has invoked drainTo() method on a blocking queue and other one is calling add() or put() on the same queue, is the queue’s state consistent at the end of both the operations?

Answer 1

I think you are confusing the terms “thread-safe” and “atomic”. They do not mean the same thing. A method can be thread-safe without being atomic, and can be atomic (for a single thread) without being thread-safe.

Thread-safe is a rubbery term that is hard to define without being circular. According to Goetz, a good working model is that a method is thread-safe if it is “as correct” when used in a multi-threaded context as it is run in a single-threaded context. The rubberyness is in the fact that correctness is subjective unless you have a formal specification to measure against.

By contrast, atomic is easy to define. It simply means that the operation either happens completely or it doesn’t happen at all.

So the answer to your question is that drainTo() is thread-safe, but not atomic. It is not atomic because it could throw an exception half way through draining. However, modulo that, the queue will still be in a consistent state, whether or not other threads were doing things to the queue at the same time.

---

(It is implicit in the above discussion that the specific implementation of the BlockingQueue interface implements the interface correctly. If it doesn’t, all bets are off.)