I need to have a thread-safe LIFO structure and found that I can use thread-safe implementations of Deque
for this. Java 7 has introduced ConcurrentLinkedDeque
and Java 6 has LinkedBlockingDeque
.
If I were to use only the non-blocking methods in LinkedBlockingDeque
such as addFirst()
and removeFirst()
does it have any difference to ConcurrentLinkedDeque
?
i.e. If you disregard the blocking aspect, is there any other difference between ConcurrentLinkedDeque
and LinkedBlockingDeque
, apart from LinkedBlockingDeque
being bounded?
Concurrent insertion, removal, and access operations execute safely across multiple threads. A ConcurrentLinkedDeque is an appropriate choice when many threads will share access to a common collection. Like most other concurrent collection implementations, this class does not permit the use of null elements.
The implementation provides by the LinkedBlockingDeque is thread-safe. All queuing methods in the class achieve their effects atomically using ReentrantLock internally.
The LinkedBlockingQueue is an optionally-bounded blocking queue implementation, meaning that the queue size can be specified if needed. An unbounded queue implies that the size of the queue is not specified while creating. Therefore, the queue can grow dynamically as elements are added to it.
ArrayBlockingQueue is bounded which means the size will never change after its creation. LinkedBlockingQueue is optionally bounded which means it can optionally have an upper bound if desired. If no upper bound is specified, Integer.
To quote the great Doug Lea (my emphasis)
LinkedBlockingDeque vs ConcurrentLinkedDeque
The LinkedBlockingDeque class is intended to be the "standard" blocking deque class. The current implementation has relatively low overhead but relatively poor scalability. ...
... ConcurrentLinkedDeque has almost the opposite performance profile as LinkedBlockingDeque: relatively high overhead, but very good scalability. ... in concurrent applications, it is not all that common to want a Deque that is thread safe yet does not support blocking. And most of those that do are probably better off with special-case solutions.
He seems to be suggesting that you should use LinkedBlockingDeque
unless you specifically need the features of ConcurrentLinkedDeque
.
ConcurentLinkedDequeue is lock-free (see comments in source code) while LinkedBlockingQueue uses locking. That is the former is supposed to be more efficient
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With