> I don't know, in which way would a doubly-linked list make a better > concurrent queue ? I thought that having to update both ends of a node > (prev,next) would make it slower.
My bad, since you use `cas` for the operation, it indeed only (or have to) update one end. I saw you put `while` in both queue and dequeue so I think double-linked would be faster, O(1) btw. > true, but he did benchmark that. What would you rather suggest? Transaction, since you're using atomic. If you insist avoiding lock, make the dequeue a transaction. Although I don't know which is costly between using lock-and-unlock mutex or failed transaction. The original poster said "Mutex are relatively heavy", I don't know relative to what. > what do you mean ? dequeueNode() uses a lock to return the result Again, I just realized you're using `Option` instead of usual `proc` that check whether queue is empty or not.
