Using LinkedBlockingQueue good enough for multi thread java program?

8
votes

I have a consumer and a producer that adds and deletes Item objects from the queue. If I use the put() and take() methods. Is there any thread safety issues I need to still cover? This is similar to the bounded buffer problem and I was just wondering if using the blocking queue instead replaces the need for semaphores or monitors. The Item object itself would probably need synchronization (setters but getters don't need lock), am I right? And lastly, I'm not quite sure how to test if it is thread safe since I can't simultaneously make both threads call the take() because to order of execution is underterministic. Any ideas? Thanks.

2
javamultithreadingqueue
While the order of execution is nondeterministic, wouldn't the evidence that LBQ is not good enough be if some items you put() don't appear, or the same item item shows up repeatedly in the results from take()? – michel-slm
I guess that is a possible test but it might not always be a thread specific test. Maybe using thread sleep in the middle of calling take() while other thread calls it too? – Dan
Its what Executors uses by default which leads me to the question; can you not use an ExecutorService which wraps a Queue and a Thread Pool? – Peter Lawrey

2 Answers

7
votes

It is perfectly thread-safe for what you're doing, in fact this is what it's designed for. The description of BlockingQueue (which is the interface implemented by LinkedBlockingQueue) states:

BlockingQueue implementations are thread-safe. All queuing methods achieve their effects atomically using internal locks or other forms of concurrency control.

1
votes

Simultaneous put() and take() are not thread-safe since they use 2 different locks.

This is already answered here : Are LinkedBlockingQueue's insert and remove methods thread safe?