[cpp-threads] Somewhat relevant technical report

[Herb Sutter]

I don't think you need to craft standardese yet, if it would delay the
paper. The primary goal of this would be to have a concrete and crisp
proposal that people could agree/disagree with, which will be discussed
in English specification rather than the details of the standardese.
Once the EWG decides they love it (possibly with changes) is when we'll
know what wording to craft. If you're pretty sure they'll like it, then
it'd be fine to craft strawman wording now, but you might be expending
extra time -- generally I try to save my time by doing that only when I
know that the committee has a consensus on the proposal's details, else
there's more rework/updating of standardese as the committee
discusses/changes/etc.

Re sequence points: I would have a section in the proposal that
explicitly raises this issue, with enough discussion/examples so that
the issue is clear, and let that be part of the EWG discussion. They can
let you know how they prefer the standardese to be written.

Thanks!

Herb


> -----Original Message-----
> From: cpp-threads-bounces at decadentplace.org.uk [mailto:cpp-threads-
> bounces at decadentplace.org.uk] On Behalf Of Boehm, Hans
> Sent: Monday, December 19, 2005 11:57 AM
> To: C++ threads standardisation
> Subject: RE: [cpp-threads] Somewhat relevant technical report
> 
> Herb -
> 
> My goal is to have the foundations worked out by the Berlin meeting,
and
> hopefully to have some confidence that they are correct this time
> around.  I would also like to have a better draft of the atomic
> operations interface by then.
> 
> I'll make another pass at the strawman proposal on the web site asap.
> 
> In the slightly longer term, I'm not very confident that I can draft
the
> appropriate standardese without substantial help.  Will you have time
to
> help with that?  Are there other standardese experts on this list who
> can help with beating the text into shape?
> 
> In working towards the standardese, I think I would be inclined to
> replace any mention of "sequence point" with some other term like
> "occurs before".  As I mentioned on the reflector, sequence points are
> really used to describe an ordering, which is confusing.  And IIRC,
> Clark Nelson pointer out that sequence points aren't used consistently
> in the standard anyway.  In my mind, it makes no sense to me to try to
> build an easily understandable thread semantics on a needlessly
> confusing sequential semantics.  We don't want to lose readers before
> they even get to the interesting part.
> 
> Do you think this would fly in the committee, or is there enough
history
> here that we shouldn't touch sequence points?
> 
> My reading is that the reflector discussion about fixing argument
> evaluation order is not likely to go anywhere, and we should ignore
it,
> at least for now?  (I'm not suggesting that it shouldn't go anywhere,
> only that it didn't seem to.)
> 
> Hans
> 
> > -----Original Message-----
> > From: cpp-threads-bounces at decadentplace.org.uk
> > [mailto:cpp-threads-bounces at decadentplace.org.uk] On Behalf
> > Of Herb Sutter
> > Sent: Monday, December 19, 2005 6:24 AM
> > To: C++ threads standardisation
> > Subject: RE: [cpp-threads] Somewhat relevant technical report
> >
> >
> > Great -- btw, what's your expected timeframe on this? Just
> > wondering how much we could hope to see in Berlin (in a draft
> > form of course)...?
> >
> > Herb
> >
> >
> > > -----Original Message-----
> > > From: cpp-threads-bounces at decadentplace.org.uk
[mailto:cpp-threads-
> > > bounces at decadentplace.org.uk] On Behalf Of Nick Maclaren
> > > Sent: Monday, December 19, 2005 1:06 AM
> > > To: C++ threads standardisation
> > > Subject: RE: [cpp-threads] Somewhat relevant technical report
> > >
> > > Hans Boehm <Hans.Boehm at hp.com> wrote:
> > > >
> > > > We haven't so far thought very much about some of Nick's major
> > concerns,
> > > > e.g. which functions can be used to synchronize between threads,
> > > possibly
> > > > transitively through other processes.  I would prefer to address
> > these
> > > > issues only for C++ library functions, but to provide a clean
and
> > > > extensible framework that can be used for extending the spec to
> > other
> > > APIs
> > > > such as Posix or win32 or higher level libraries.
> > >
> > > I agree that this is the right strategy.  In fact, I would
> > include the
> > > framework as part of the basic model (but have it purely
> > generic, so
> > > it made no reference to any specific functions), and add the C++
> > library
> > > functions as a second step.  With iterative refinement where
> > necessary,
> > > of course.
> > >
> > > I don't think that the second step would be hard, once the
concepts
> > > are clear, but would need careful thought and wording.
> > >
> > > And, if it were done right, extending it to POSIX would be simple,
> > > though it would define an extension of POSIX and not
> > anything based on
> > > the current specification.
> > >
> > >
> > > Regards,
> > > Nick Maclaren,
> > > University of Cambridge Computing Service,
> > > New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
> > > Email:  nmm1 at cam.ac.uk
> > > Tel.:  +44 1223 334761    Fax:  +44 1223 334679
> > >
> > > --
> > > cpp-threads mailing list
> > > cpp-threads at decadentplace.org.uk
> > >
http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
> >
> > --
> > cpp-threads mailing list
> > cpp-threads at decadentplace.org.uk
> > http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads
> >
> 
> --
> cpp-threads mailing list
> cpp-threads at decadentplace.org.uk
> http://www.decadentplace.org.uk/cgi-bin/mailman/listinfo/cpp-threads