@Araq: > Looks ok but suffers from the usual problem that allocations/deallocations > are ignored and these too can block. (In pretty much every allocator that is > used in production. Note that Nim's is particularly bad since it uses a > single global lock in allocShared...)
Dang it ! What would you rather suggest ? I saw that nodes in `sharedlist.nim` hold an array instead of a single value, but then it uses a single global lock even for iterating (that's the reason I wrote this in the first place) But I don't usually write my own concurrent data structures, hence the feedback request @mashingan: > Thanks, do you not consider using double-linked list as queue? 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. > Also, in that post mentioned "Mutexes are relatively heavy" but then in his > post he used lock & unlock for dequeue. true, but he did benchmark that. What would you rather suggest? > Although I think even for reading the queue whether it's empty or not, you > still need to make it atomic or locking to avoid data-races. what do you mean ? `dequeueNode()` uses a lock to return the result
