.NET 4 includes new concurrent data structures. The Bag and Dictionary collections have obvious applications but I cannot see any use for the Queue and Stack data structures. What are people using these for?
Also, I've noticed that the design based upon linked lists incurs a lot of allocation and that destroys scalability. This is surprising given that the sole purpose of these collections is multicore programming. Is this an inherent limitation or are they just badly implemented?
The fairly obvious scenario for a queue would be one (or more) threads putting work items in the queue, and several worker threads extracting them for concurrent processing.
I'd imagine that linked-list based design is to make it lock-free. What's wrong with the scalability of that, and which other options did you have in mind?
Stacks and Queues are incredibly useful in concurrent programming, just as in sequential programming.
The new ConcurrentQueue<T> and ConcurrentStack<T> classes provide a very nice, thread-safe implementation of a Queue and a Stack. These are particularly useful when dealing with multi-threaded producer/consumer scenarios, as both classes are lockless (good for scalability) and threadsafe, as well as fairly performant.
Also, I'd like to point out one thing - you have two misconceptions in your second paragraph. Linked lists are not particularly bad for scalability. Memory allocation ~may~ need to occur regularly (though there are ways to combat this), but often, that is a smaller price to pay than other potential issues in terms of scalability. (This really depends on the scenario...) Also, the new ConcurrentQueue<T> and ConcurrentStack<T> classes are not based on a (at least traditional) linked list. They're a lockless class which internally uses a linked list of arrays to hold the elements, more like std::deque.
Addressing the second part of your question, you are quite right that although concurrent collections implementations in .Net 4.0 are trying to be lock-free, they still sit on top of non-lock-free memory allocation subsystem.
Memory management is a bane of all lock-free data structures: here is a nice presentation on the state of the art: http://sysrun.haifa.il.ibm.com/hrl/ISMM2009/program.html#7
The bottom line is that this area is very much research-in-progress, so probably not yet quite ready to be included in wide-deployment production platforms such as .Net.
Here a recent blog post which covers precisely the question you are after (GC issues with using ConcurrentBag and TPL), suggests ways to discover and analyze this in the field (VS2010 Concurrency Visualizer). The use of Server GC is suggested for partial solution.