[cpp-threads] modes, interlude

[Boehm, Hans]

Some higher level issues before we dive back into the details:

1) I think the implicit assumption in this discussion has been
that the simplest solution has been the one with the smallest
number of primitives, where a primitive is a memory operation
with an ordering constraint.  I'd actually like to see us
minimize the number of ordering constraints, but implement
each ordering constraint with every memory operation for which
it makes any sense at all.  It seems to me that disallowing
meaningful combinations actually adds complexity.  (I think the
discussion sort of moved there anyway, but I wanted to make it
explicit.)

2) I do like the idea of providing the ordering constraint as a
template or function argument.  It makes it much easier for the user
to implement the "atomically multiply by 17 and add 1" function
in terms of CAS, without redoing it for every possible ordering
constraint.  And that reinforces point (1).  Do we all agree?

3) Getting back to an earlier discussion about emulations, one
option might be to provide two templates locked<T> and atomic<T>,
where atomic<T> provides lock-free implementations of at least
atomic loads, stores, CAS, and fetch_and_op, or none of those,
with a feature test to determine whether it's usable, and
locked<T> provides the same operations, with a lock-based
emulation if it's not feasible.  This seems to avoid the silent
failure scenarios.  (There's still a question about where to
put useful but rarely implemented primitives like DCAS or
Itanium cmp8xchg16.  In another class, with feature tests for
each?)

4) Assuming the approach in point (3), I'm not sure where
"fallible CAS" fits in.  Are there cases in which the infallible
version occurs enough of a performance loss to justify the other
version?  Or are we trying to guarantee wait-free implementations?
I think the latter is hard if we try to apply it to fetch-and-op,
since the emulations at least get much more complicated?

5) I think we need to avoid primitives with strange optimization
requirements on other code.  On many architectures, we can't
expose LL/SC directly, since it breaks if there are any register
spills in the middle.  We can't require ordering for control-
dependent code, since that inhibits transformations in other
parts of the program.  We need higher-level primitives for these
things if they're not otherwise avoidable.

Hans 

> -----Original Message-----
> From: 
> Cpp-threads_decadentplace.org.uk-bounces at decadentplace.org.uk 
> [mailto:Cpp-threads_decadentplace.org.uk-bounces at decadentplace
> .org.uk] On Behalf Of Doug Lea
> Sent: Monday, May 09, 2005 6:59 AM
> To: cpp-threads at decadentplace.org.uk
> Subject: [cpp-threads] modes, interlude
> 
> 
> 
> For people not paying attention (which I wouldn't if I
> were most of you :-). Here's the (probably biased) executive summary.
> 
> We're trying to define operations on atomics. It's harder 
> than it looks.
> 
> Some of us want this set to be small, mainly because we need 
> to provide full semantics for all of them and their interactions.
> 
> Some of us want this set to be large, mainly so programmers 
> can have more fine-grained control.
> 
> Among the complicating factors:
> 
> 1. There are semantic differences across processors of instructions vs
>     barrier abstractions. Some of which are subtle.
> 
> 2. There are cost differences in mapping different barrier 
> abstractions
>     to different processors, that may or may not persist in 
> the face of
>     common expected optimizations.
> 
> 3. There are differences between memory-model-speak and 
> sequence points.
>     (And maybe differences between barrier abstractions and the
>     underlying memory model semantics.)
> 
> 4. We don't know where to place the thresholds of what properties
>     of known platforms should be ignored (requiring programmers
>     to resort to assembly to use them) vs those that should 
> be abstracted
>     over to provide a common set of functionality, vs those 
> that should
>     be feature-tested.
> 
> 
> -Doug
> 
> 
> 
> 
> -- 
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk 
> http://decadentplace.org.uk/mailman/listinfo/cpp-threads_decad
entplace.org.uk