[cpp-threads] Alternatives to SC

[Paul E. McKenney]

On Thu, Jan 11, 2007 at 10:22:11PM -0800, Hans Boehm wrote:
> 
> 
> On Thu, 11 Jan 2007, Paul E. McKenney wrote:
> 
> > Since we don't have SC now, a more appropriate answer is "what would SC
> > buy us?".  Thus far, your answers have not been convincing to me.
>
> I'm not sure we're all talking about the same thing here.  I think
> we're only talking about SC for specially marked atomics.  We are all
> assuming that for C++ races on ordinary variables are disallowed,
> with perhaps minor disagreements about the semantics of "disallowed".
> Thus the hardware and compiler are allowed to implement operations
> on ordinary variables essentially as they do now.

This is in fact what I understood.  I have deep reservations about
legislating SC even for specially marked atomics.

To see the basis of my concerns, please consider a generalization of
the example that Peter Dimov recently posted to this thread (with your
corrections) from 4 threads to N+2 threads.  Please especially consider
the case where the two readers are running on different dies, but each
sharing dies with different writers.

> We do clearly have sufficient hardware support to support such as SC atomics
> adequately on some platforms.  (Amusingly, Alpha is probably one of those?)
> We have issues, or at least lack of clarity, on others.

I don't have access to an Alpha to test this out.  Can Alpha really be
made to fully order independent writes to independent variables across
all CPUs?  Running Peter's example requires four CPUs, and is greatly
eased given a fine-grained low-overhead time source that is synchronized
across all CPUs.

I believe that I have a couple examples thus far from a couple of
companies of current machines (with different major CPU families)
that do -not- provide SC atomics without great pain (e.g., having the
compiler intuit where to insert locking), but am still tracking this down.
I may have to bite the bullet and wean my test program off of its current
dependence on the aforementioned time source.  :-(

Finally, a word of caution.  A number of HW architects I have talked
to thus far did not initially appreciate SC's requirement for ordering
of independent writes from independent processors.  You might want
to double-check your conversations in case the HW architects you were
talking to are also missing this twist of SC.

> (As far as I know, there even seem to be a few platforms that provide full SC
> for all loads and stores, namely current hardware PA-RISC processors,
> and possibly MIPS.  This suggests to me that at least empirically the
> hardware tradeoffs are not obvious.  But I don't think anyone wants to
> restrict us to fully SC hardware, certainly not I.)

But isn't it the case that all companies making multiprocessor machines
based on PA-RISC and MIPS are transitioning to other CPU types, and
have been for quite a few years?

At first glance, Doug Lea's proposal looks pretty good to me, though
I certainly cannot claim to fully understand it yet.  As I currently
understand it, his model captures the most valuable aspects of SC while
imposing only a minimal straightjacket for compiler writers and CPU/system
designers.

What problems does his proposal pose from your viewpoint?

							Thanx, Paul