<div dir="ltr">On Sun, Aug 25, 2013 at 3:18 PM, Mathieu Desnoyers <<a href="mailto:mathieu.desnoyers@efficios.com">mathieu.desnoyers@efficios.com</a>> wrote:<br>><br>> I'm not very comfortable with your DQ implementation not providing any<br>
> kind of guarantee to a forward traversal followed by backward traversal,<br>> nor for backward followed by forward traversal. If a list add is<br>> executed concurrently with traversals, and we can ensure there are no<br>
> list del of the node, if a traversal sees the added node when doing<br>> forward iteration, I would clearly expect to still see it if a backward<br>> iteration follows.<br>><br>> I took the liberty of implementing a couple of ideas I had to provide<br>
> a RCU DQ with those guarantees. I just pushed the code here (beware, I<br>> just did some basic single-threaded unit tests so far, so consider this<br>> code as largely untested concurrency-wise):<br>><br>>   git clone git://<a href="http://git.urcu.io/urcu.git">git.urcu.io/urcu.git</a><br>
>   branch: rcudq<br>>   file: urcu/rcudq.h<br>><br>> Direct link to the file via gitweb:<br>>   <a href="http://git.lttng.org/?p=userspace-rcu.git;a=blob;f=urcu/rcudq.h;h=4a8d7b0d5143a958514cf130b1c124d99f3194ca;hb=refs/heads/rcudq">http://git.lttng.org/?p=userspace-rcu.git;a=blob;f=urcu/rcudq.h;h=4a8d7b0d5143a958514cf130b1c124d99f3194ca;hb=refs/heads/rcudq</a><br>
<br><div style>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. </div>
<div style><br></div><div style>Mike</div><div style><br></div><div style>Mike Day | <a href="mailto:ncmike@ncultra.org">ncmike@ncultra.org</a> | +1 919 371-8786 </div></div>