Return to Answer

Without the larger context it's hard to know whether having one queue reading from other queues is really the best design.

Some possible ideas, which I can't choose between without further clarification:

• Eliminate the smaller queues and just make one big master queue. If other parts of the system need to read from it, that business logic can be handled before objects are put on the queue or after they are taken off.
• Rather than having one master queue, have a java.util.Map whose values are queues. You can use Thread.wait and Thread.notify to notify listeners that a new element is available, or use a more explicit listener pattern if that's needed.
• As @toto2 said, there may be something in java.util.concurrent that is the best fit. In particular java.util.concurrent.locks.ReadWriteLock may be useful.

The Producer/Consumer threads using a Queue design pattern may also be worth checking out.

Without the larger context it's hard to know whether having one queue reading from other queues is really the best design.

Some possible ideas, which I can't choose between without further clarification:

• Eliminate the smaller queues and just make one big master queue. If other parts of the system need to read from it, that business logic can be handled before objects are put on the queue or after they are taken off.
• Rather than having one master queue, have a java.util.Map whose values are queues. You can use Thread.wait and Thread.notify to notify listeners that a new element is available, or use a more explicit listener pattern if that's needed.
• As @toto2 said, there may be something in java.util.concurrent that is the best fit. In particular java.util.concurrent.locks.ReadWriteLock may be useful.

The Producer/Consumer threads using a Queue design pattern may also be worth checking out.