Add multiple objects to a Deque to be retrieved in that order?

Question

All:
We are using a LinkedBlockingDeque in a classic producer/consumer setup -- multiple threads may post "commands" to the Q, and the consumer retrieves and executes each command in a separate thread.
We have very rare cases where we need to post more than 1 command which must be executed by the consumer in the order posted (with no intervening commands).
Something like addAll(Collection c) represents what we need, but as far as we know does not guarantee that all of the elements in 'c' will be added to the Deque without the presence of intervening elements being posted from other threads. (If this understanding is not correct, then addAll(..) does what we want and there is no problem.)
We understand that we could use a LinkedList with a concurrency wrapper, and handle synchronization where required. But do really like the functionality provided by a LinkedBlockingDeque and hate to have to handle all the complexity in our own code. (Not to mention the ton of existing code that would have to be retrofitted!)
We also understand that we can define a new "commandSet" object which represents the list of primitive commands that must be processed in order. But this also seems like a lot of unnecessary clutter.
Is there another way to pass a set of "commands" into the Deque and be assured that they will be retrieved in that order by the consumer?
If there is no such mechanism, would it be worth requesting such an enhancement -- something like addAllTogether(Collection c) which would synchronize internally so that all the elements in 'c' are added in sequence?
Thanks.

Answer 1

Thanks for your response, and yes you are correct -- CommandSet is misleading and it should have been CommandList.
It still seems to me that in general with all the Concurrent... implementations it might be useful to have some form of atomic addAll(Collection c) method -- maybe addSynchronized(Collection c). (There's got to be a better name!)
This method would guarantee that all of the elements of 'c' are added to the Concurrent.... object without any conflicting adds or removes posted by any other thread.
I understand the CommandList construct, and this is in fact how we resolved the issue. But in general this has some limitations. Using a Deque as an example, but applying this to all Concurrent.... classes:
1) Our design is not as clean as the structure you have in your response, and it really can't easily support that type of interface. The purpose of the Consumer is to interrogate each X in the queue, and act as an interface to "perform" that logical operation on a specific device. So it invokes many methods of X in order to perform it's job. I.e. are you inbound or outbound, how much data, what device address should this go to, etc, etc.
I also understand that we could define another interface and pass an 'execute' object into the 'execute' method -- something like 'execute(theExecuteInstance(this))' to get around this -- but now we're really starting to add complexity!
2) You are now adding a different object type to the Deque. If it was instantiated as, say LinkedBlockingDeque<X> then the only way to add a List of X objects is to declare class ListOfX extends X which would really be a confusing structure. This one has kludge stamped all over it! (But, hey, that's what we did!)
3) Clearly, the whole approach only works if you have access to the code for the Consumer side and can modify it to understand the ListOfX instance and handle it correctly.
If we had realized at the start that the situation would arise in which multiple Xs would need to be Consumed in sequence, then we would have defined ListOfX (more cleanly than above) and declared the Deque as LinkedBlockingDeque<ListOfX>, and written the Consumer to handle this.
But as happens so often, we were well down the road before this situation arose .... with the inevitable patchwork solution.
On the other hand, you could probably still make a case for some form of addSynchronized in general. It does seem like a natural situation that should be supported cleanly.
If we weren't using a Concurrent ... object, and handling our own synchronization, then this structure follows naturally because you would just synchronize on the object, run an iterator through 'c' and add each instance returned. With one of the Concurrent... objects, this pattern has been lost.
Even if we had realized the need earlier, and defined a ListOfX right from the start, it still clutters up the situation (the Consumer really just wants to process X's), and adds the overhead of instantiating ListOfX, and adding a single X to the list, for 99% of the actual cases.
But thanks for your response and insight. Maybe next time we'll figure out all the use cases before we start (LOL).