On Sun, Aug 25, 2013 at 3:18 PM, Mathieu Desnoyers <
address@hidden> wrote:
>
> I'm not very comfortable with your DQ implementation not providing any
> kind of guarantee to a forward traversal followed by backward traversal,
> nor for backward followed by forward traversal. If a list add is
> executed concurrently with traversals, and we can ensure there are no
> list del of the node, if a traversal sees the added node when doing
> forward iteration, I would clearly expect to still see it if a backward
> iteration follows.
>
> I took the liberty of implementing a couple of ideas I had to provide
> a RCU DQ with those guarantees. I just pushed the code here (beware, I
> just did some basic single-threaded unit tests so far, so consider this
> code as largely untested concurrency-wise):
>
> git clone git://
git.urcu.io/urcu.git
> branch: rcudq
> file: urcu/rcudq.h
>
> Direct link to the file via gitweb:
>
http://git.lttng.org/?p=userspace-rcu.git;a=blob;f=urcu/rcudq.h;h=4a8d7b0d5143a958514cf130b1c124d99f3194ca;hb=refs/heads/rcudq
Mathieu - Thanks for the review! And thanks for the code, I'm working with it right now. I like the idea of using a flag to provide a form of atomicity for the doubly-linked list elements. I'm also planning on running some timing tests to see of the additional memory barriers and atomic accesses make *any* difference whatsoever.
Mike