Ranadhir Nag wrote:NOt exactly sure how a blocking queue may help in this case - maybe a task queue with threadpool?Though not sure how.
The idea that I needed help on is whether a used-case like this - where every read is accompanied by a removal of the read data from the container is a good case for ConcurrentHashmap.
No, a Map of any sort is a container for accessing data based on a Key. A Queue is the perfect type of container for a Read/Remove in an orderly fashion. The method you use is remove(). As Martin said, one good sub-family of Queue is a BlockingQueue. These allow consumers (the threads taking things from the collection) to wait until there is data available, and for producers to wait until there is room in the Queue. You would use take() and put() for these tasks respectively. The BlockingQueue implementations are nice in multi-threaded environments because the consumers and producers work at different ends of the Queue, reducing the synchronization needs, and also have built-in behavior for what should happen in cases of empty or full situations.
Ranadhir Nag wrote:This is considering the fact taht a set of threads will be oeprating on the container at any given time.
Or is it better to go with a HashTable(fully synchronized).
No, don't use Hashtable. Firstly, it isn't fully synchronized, to use it safely you will have to add your own synchronization. Second, the data structure doesn't fit your requirements as specified so far. And third, if you do need a Map interface then any other Map implementation in the java.util.concurrent package will do a better job at thread-safety and efficiency than Hashtable.
So: why do you think you need a Map? Do you have Key/Value pairs? So far your description does not mention any. Do you need uniqueness in the values stored in the collection?