would a LinkedList be a possible implementation in producer-consumer multithread application with an external sync object when used as fifo-deque?
to explain: I may have an arbitrary number of producer threads and one consumer thread the time it takes to create an object can vary between faster than it can be consumed and slower than it can be consumed
also the time an object can be consumed
(these are not theoretical random values but actual encoding times depend on content)
as the order doesn't matter I'd like to produce an number of objects upfront until I hit a max threshhold, put the producer threads on wait on an sync object, and call notifyAll from the consumer when hitting below minimum threshhold
actual I didn't implemented this myself as I'm still struggle with multi-thread basics (all I done until now was all singlethreaded)
wouldn't I encounter the same issue as I'm altering the List while accessing it even I'm not using an Iterator?
Why use a Deque, and why use a LinkedList? Deque does more than you need, and implementations based on linked nodes are almost always deficient compared to array based implementations.
From your description it seems like you only require a Queue where the producers add to one end and the consumers take from the other side. Your requirement that producers wait for there to be space in the queue, and consumers wait for there to be elements in the queue makes BlockingQueue an excellent fit. An added benefit is that ALL BlockingQueue implementations are thread-safe, so you don't have to worry about synchronization.
Now, there are a couple of implementations of BlockingQueue. After eliminating double ended and linked queues, these are the remaining ones:
Since you don't need delays and you need to be able to buffer produced elements, DelayQueue and SynchronousQueue are out. You can use either ArrayBlockingQueue or PriorityBlockingQueue, depending on whether you want your produced elements to be consumed based on some kind of priority.