[cpp-threads] Web site updated

[Lawrence Crowl]

On 2/13/07, Paul E. McKenney <paulmck at linux.vnet.ibm.com> wrote:
> On Tue, Feb 13, 2007 at 07:26:09PM -0000, Boehm, Hans wrote:
> > >
> > > MMIO accesses, anyone?  Hardware timing analysis (especially
> > > if there is a short loop between the two)?
> > >
> > > Let's please just outlaw that sort of optimization for
> > > store_raw(), so that it can retain its full meaning.
> > >
> > My understanding is that we are constrained here as to what we can
> > require in normative standards text.  Any program using memory mapped IO
> > or relying on timing is clearly using features well beyond the standard,
> > and hence we can't say anything about its behavior.  I think that's one
> > problem with the original, imho not very successful, attempt to define
> > "volatile" in the standard.
> >
> > In general, we cannot formally prohibit any compiler transformation that
> > is not observable in a conforming program.  We are probably a bit more
> > constrained, in that I don't think we can require anything that implies
> > fairness, since we almost certainly want nonpreemptively scheduled
> > threads packages to conform.  (This constraint probably doesn't apply to
> > Microsoft's PRISM, and they may want to diverge here.)
> >
> > I am less clear as to what we can reasonably suggest as nonbinding notes
> > in the standard.  And I suspect we can express intentions like this
> > there, but this will not result in a binding requirement.  It may
> > nonetheless be observed, since I doubt you will get much benefit on
> > standard benchmarks by combining atomic operations or the like.
>
> These constraints seem completely at odds with any attempt to define
> something that works in a multithreaded environment.

We can and should define what is necessary to achieve reliable
multi-threaded operation.  The question then becomes "what is reliable?".
For that you have some testability requirements.  As a matter of
philosophy, for good performance reasons, the committee does not want
to choose between implementations that are not observable in the source.

On the other hand, the committee cannot mandate good performance.
Any performance constraints should be worked out between you and
your vendor.  In practice, it is a competitive world, and anyone that
needs a good performance implementation can get one.

>
> I suppose one could separately call out the non-binding notes that are
> absolutely required in order to attain reliable multithreaded operation.
> Any experience with this approach?

We can certainly state our intent, as long as it does not conflict with the
normative text, but the implementations must be free to ignore those
notes for unusual situations.  In practice, vendors have problems if they
do not "go with the flow" of common practice because programs are
often do not strictly conform to the standard.

-- 
Lawrence Crowl