[cpp-threads] Yet another visibility question

[Chris Thomasson]

>                                                    (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


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.


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)