[cpp-threads] Yet another visibility question

[Boehm, Hans]

> From: Peter Dimov
> 
> Hans Boehm wrote:
> 
> > The intent is definitely not to require per-variable TSO 
> for ordinary 
> > variables.  As you point out, it probably doesn't matter which way 
> > it's stated here.  But I think it's cleaner to explicitly only talk 
> > about synchronization operations.
> 
> Just to clarify, "ordinary variables" is a shorthand for 
> "variables read or written using ordinary operations", right? 
> We won't require explicit tagging to distinguish "atomic 
> variables" from "ordinary variables", I hope. :-)
Actually, in Lawrence's and my current draft proposal, we do
distinguish.  There are atomic types, even at the C level.   This was
discussed at past meetings.  IIRC, the argument basically went that

- This results in cleaner code.  We really do want people to state at
the point of declaration that something is being concurrently accessed.
- You don't absolutely need identical alignment for the atomic and
nonatomic variants.
- It would be hard to implement atomic operations on ABIs that require
only byte alignment if the atomic operations applied to ordinary, say,
int's.
- In spite of earlier arguments to the contrary, it doesn't really seem
to adversely impact the issue of adapting old code to the new API.  The
old code only works if the data is sufficiently aligned through some
other means (e.g. the ABI).  A high quality implementation will need to,
and can, ensure that T and atomic_T have identical size, and that
casting a sufficiently aligned T* to an atomic_T * and applying atomic
operations to the result works correctly.  It may make sense to put
(nonbinding) words of encouragement to that effect in the standard.
Thus there should be a way to update old interfaces without affecting
the ABI.  And if necessary, there is a way to apply the new operations
to data whose declaration you don't have control over.

> 
> "All atomic modifications to a location or lock L occur in 
> some particular total order, called the modification order of L"
> 
> maybe? 
> 
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
>