[cpp-threads] Web site updated

[Paul E. McKenney]

On Sat, Feb 03, 2007 at 12:57:00PM -0800, Hans Boehm wrote:
> 
> I updated the web site at
> 
> http://www.hpl.hp.com/personal/Hans_Boehm/c++mm/

Good stuff!!!

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

Good arguments from my point of view -- all the environments I
have worked with do in fact require some sort of tagging, either of
variables (volatile) or of code paths (explicit fences).  For backwards
compatibility, individual compilers will likely need to continue
respecting these sorts of directives for some time to come.

>     * Why do our atomic operations have integrated memory ordering
> specifications?

My first reaction was to give you a hard time about the locking
example, as locking primitives are almost always hand-crafted.
In any case, given load_raw(), store_raw(), and explicit memory
barriers as "escapes" for those rare occasions when they are
badly needed, integrating memory ordering specifications into
normal atomics becomes more palatable.

>     * Why do we not guarantee that dependencies enforce memory ordering?

In the suggestion at the end of the document, wouldn't it be reasonable
to disallow application of profiling-based optimizations to quantities
that derive from load_raw()?  Should be a matter of tagging, correct?
This might well force a global view during profile-based optimizations,
but such a global view might well enable much more powerful optimizations.

Now, about a store_raw() -- you guys OK with this, for example, for
split per-thread counters?  No implicit barriers or additional dependency
checking, and no atomics except as needed by complex or unaligned
data items.

Then explicit memory barriers, though not necessarily as a replacement
for those that you are proposing in atomic accesses.

>     * Why do our ordering constraints not distinguish between loads and
> stores, when many architectures provide fences that do?

This example certainly underscores my estimate of the value of
hardware-enforced ordering based on data dependency.  This leaves Alpha,
which does not enforce such ordering.  However, it also ends up being
OK with this example, but by accident, because it has no memory barrier
that orders only loads.  Any attempt to order only loads on Alpha gets
you the full memory barrier.

Cute example, though!

						Thanx, Paul

> Hans
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads