3 ms·
Actually, concurrency is some of the use cases (among others). The structure is not useless at all, actually, the opposite is true. Further, I think your analy
by lysium 13y ago
Actually, concurrency is some of the use cases (among others). The structure is not useless at all, actually, the opposite is true. Further, I think your analysis is underspecified if not wrong.
If thread A and B share the same q initially, both will receive the same object when dequeuing. If they enqueue, both will end up with a different q: thread A's q will have elemA, thread B's q will have elemB. It does not matter whether the operations happen concurrently or not.
If thread A and B shared a non-functional data structure q, you would have to synchronize your queues between threads, otherwise "anything can happen". With functional data structures you only have to synchronize them when you actually want them to be synchronized (eg. A&B taking work orders from a common queue vs. A&B executing the same work orders twice in parallel). In addition, the synchronization involves only sharing the "current" data structure, no synchronization happens within the data structure's implementation.
- taeric 13y agoI think the question was more of how oddly this goes with the "multiple workers placing data on a queue" or the "multiple workers taking data off of a queue." In either of those cases, there will still have to be synchronization over the queue/dequeue logic such that a workers contribution is accounted for correctly. The only use case for the persistent container I can think of is specifically when the container is being passed around by multiple threads. That is, if your concern is what is going into the container, then a mutable version likely has you covered rather well. If your concern is, instead, on passing around the collection, the persistent ones have an advantage in reasoning. (Though, again, the common case of a queue is to be manipulated...)