[cpp-threads] Web site updated

[Doug Lea]

Hans Boehm wrote:
> I updated the web site at
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/
> 
> In particular, I finally added the promised rationale documents under the
> seventh bullet:
> 
>     * Why do we leave semantics for races on ordinary variables completely
> undefined?
>     * Why do our atomic operations have integrated memory ordering
> specifications?
>     * Why do we not guarantee that dependencies enforce memory ordering?
>     * Why do our ordering constraints not distinguish between loads and
> stores, when many architectures provide fences that do?
> 


Thanks for all the work you put into these! A couple of comments
while reading...

1. As these things get further nailed down, the naming scheme
increasingly bothers me: The sense of "release" extends the
quirky usage of the term in IA64, and doesn't conform to
common memory model definitions or to most(?) programmers'
intuitions. An op_release "really" releases only if the
releasing thread doesn't care if it doesn't see updates
from other threads upon its next op_acquire.
The stronger and more common sense of
release without the read-after-write caveats
is instead now assigned to op_ordered. While I'm sympathetic
to the apparent underlying rationale that op_release is
all you need in several common idioms, I think it is just
asking for trouble to use the term in this way. To me, swapping
"ordered" and "release" would be more sensible, but probably
some scheme that doesn't use the term "release" at all would
be best. Sorry not to have a constructive suggestion about
a better name though. (In Java, we use the strange name
"lazySet" for your op_release stores. That's not very good
either, but its very oddity probably makes people more
likely to read the specs before using.)


2. The one clear-cut case of data dependency exploited in
Java final field specs could, if necessary be supported
in C++. Final field data dependencies work because the
reading thread cannot possibly have a stale value for
the indirected field: Either it has never seen it before
at all, or has not seen it since some underlying barrier
(normally as provided by GC or other VM mechanics). It would seem
possible to spec the analogous cases in C++. Of course,
doing so would make it only rarely certainly applicable,
but maybe "rare" is good enough?

-Doug