[cpp-threads] Yet another visibility question

Paul E. McKenney paulmck at linux.vnet.ibm.com
Mon Dec 25 07:12:40 GMT 2006


On Sat, Dec 23, 2006 at 08:12:56PM -0800, Chris Thomasson wrote:
> 
> >                                                    (And I don't believe
> > that the semantics of read_barrier_depends() are actually definable,
> > which was the subject of the previous discussion here.)
> 
> > By "previous discussion", you mean the emails on this list in May of 2005?
> 
> > If by "definable" you mean "precisely defined in all contexts in which it
> > could be used without getting a compilation error", then I won't argue.
> > Otherwise, as you no doubt guessed, it means that a prior fetch of an
> > index or pointer must be ordered before any subsequent dereferencing
> > using that index or pointer.  For example, in:
> 
> >	a = 1;
> >	read_barrier_depends();
> >	b = 2;
> 
> > it might or might not force any ordering.  Currently it does on Alpha,
> > but not necessarily on any other platform (x86's store ordering could
> > be defeated by compiler optimizations, for example).
> 
> Indeed. Your RCU patent applications make heavy use of atomic loads with
> data-dependency hints. Just like this:
> 
> https://coolthreads.dev.java.net/servlets/ProjectForumMessageView?forumID=17
> 97&messageID=11068

;-)  Looks interesting!  I am assuming that the "release barrier" called
out in the update is at least a store-store barrier (smp_wmb() in Linux
kernel parlance).  The readers do not seem to be modifying the stack (no
pushing or popping from what I can see), so as long as the do_whatever()
function can safely run concurrently from different threads on the same
stack element, it should be safe.

Just out of curiosity, what do you use this for?

> Now... I sure do hope that the C++ memory model that you guys finally agree
> upon will be weak enough to support them! Luckily, now that the committee is
> getting input from you, I think the odds are good that it will.

Thank you for the vote of confidence!  I guess we will see how the
discussion goes.  These sorts of algorithms are similar to recursion
in the sense that some people take right to them while others suffer
extreme cognitive dissonance when first faced with them.  So it should
be interesting!

> P.S...
> 
> Paul... I think it would be nice if you could join us over at
> comp.programming.threads. We noticed a patent applications on a lock-free
> proxy garbage collector you an Michael (SMR) invented... We would like to
> discuss your implementation and possibly introduce you to a couple of other
> algorithms... (e.g., Joe Seighs RCU+SMR and my vZOOM)

I have exchanged emails with Joe Seigh on RCU+SMR, but have not yet
come across vZOOM.  Would you have a URL for a good starting point?

						Thanx, Paul



More information about the cpp-threads mailing list