Date: Mon, 13 Jan 2020 10:21:23 -0500
Just in case it wasn't assumed, I wanted to mention that I'm ok with
submitting, and would like to be an author.
On Fri, Jan 10, 2020 at 2:05 PM Jens Maurer via SG5 <sg5_at_[hidden]>
wrote:
> On 10/01/2020 19.58, Michael L. Scott wrote:
> > I continue to have reservations about the limitation to constexpr
> functions, but I’m ok with submitting, and would like to be an author. One
> question:
> >
> > [ Note: The following holds for a data-race-free program: If the
> start of an atomic block T is sequenced before an evaluation A, A is
> sequenced before the end of T, and A strongly happens before some
> evaluation B, then the end of T strongly happens before B. If an evaluation
> C strongly happens before that evaluation A, then C strongly happens before
> the start of T. These properties in turn imply that in any simple
> interleaved (sequentially consistent) execution, the operations of each
> atomic block appear to be contiguous in the interleaving. -- end note ]
> >
> > I’m not sure I completely understand that final sentence. I would have
> guessed that we needed to say “for any sequentially consistent execution
> _there exists_ a (potentially different) sequentially consistent execution
> in which the operations of each atomic block are contiguous”. Is that
> existentiality covered by “appear to be”? After all, if atomic blocks A
> and B touch only local variables, their operations can be arbitrarily
> interleaved in a sequentially consistent execution.
>
> First of all, this is a note, so we get away with slightly sloppy wording.
>
> Second, I believe this is taken from the old TS.
>
> Third, "appear to be" means you can't tell the difference with
> standard-level C++ means. (Yes, you can tell in a debugger,
> but that's cheating.)
>
> Jens
>
>
> > - Michael
> >
> >> On Jan 10, 2020, at 12:17 PM, Jens Maurer via SG5 <sg5_at_[hidden]
> <mailto:sg5_at_[hidden]>> wrote:
> >>
> >> In the interest of not surprising anyone, I intend to submit
> >> this to the pre-meeting mailing.
> >>
> >> Anyone on the current authors list that doesn't expressly
> >> approve being there will be moved to an "Acknowledgements"
> >> section before submission.
> >>
> >> Jens
> >>
> >>
> >> On 09/01/2020 22.06, Jens Maurer via SG5 wrote:
> >>> Hi!
> >>>
> >>> After today's teleconference, I couldn't resist, so
> >>> I created a draft TS for TM-light, mostly copying
> >>> from Victor's Google doc. See attached.
> >>>
> >>> The new part is in 8.8, where we decree implementation-defined
> >>> behavior when "bad" things are evaluated inside an atomic block.
> >>>
> >>> Possibly surprising changes vs. the status quo of the discussion:
> >>>
> >>> - constexpr functions only
> >>> (as explained in the teleconference, the compiler might not retain
> >>> other functions from the same translation unit)
> >>>
> >>> - throw-expressions are forbidden entirely
> >>> (Did we want to require support for throw/catch within the atomic
> >>> block? Seems more-than-minimal.)
> >>>
> >>> - Coroutines are forbidden entirely.
> >>> (I haven't seen talk about them vs. TM. Also, they have funny
> >>> control flow.)
> >>>
> >>> This would be in time to submit to the pre-Prague meeting,
> >>> for SG1 and EWG amusement there, if I get approval on this list
> >>> until Monday.
> >>>
> >>> I've added all participants to the authors list, please complain
> >>> if that's wrong.
> >>>
> >>> Jens
> >>>
> >>>
> >>
> >> --
> >> SG5 mailing list
> >> SG5_at_[hidden] <mailto:SG5_at_[hidden]>
> >> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
> >
>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>
submitting, and would like to be an author.
On Fri, Jan 10, 2020 at 2:05 PM Jens Maurer via SG5 <sg5_at_[hidden]>
wrote:
> On 10/01/2020 19.58, Michael L. Scott wrote:
> > I continue to have reservations about the limitation to constexpr
> functions, but I’m ok with submitting, and would like to be an author. One
> question:
> >
> > [ Note: The following holds for a data-race-free program: If the
> start of an atomic block T is sequenced before an evaluation A, A is
> sequenced before the end of T, and A strongly happens before some
> evaluation B, then the end of T strongly happens before B. If an evaluation
> C strongly happens before that evaluation A, then C strongly happens before
> the start of T. These properties in turn imply that in any simple
> interleaved (sequentially consistent) execution, the operations of each
> atomic block appear to be contiguous in the interleaving. -- end note ]
> >
> > I’m not sure I completely understand that final sentence. I would have
> guessed that we needed to say “for any sequentially consistent execution
> _there exists_ a (potentially different) sequentially consistent execution
> in which the operations of each atomic block are contiguous”. Is that
> existentiality covered by “appear to be”? After all, if atomic blocks A
> and B touch only local variables, their operations can be arbitrarily
> interleaved in a sequentially consistent execution.
>
> First of all, this is a note, so we get away with slightly sloppy wording.
>
> Second, I believe this is taken from the old TS.
>
> Third, "appear to be" means you can't tell the difference with
> standard-level C++ means. (Yes, you can tell in a debugger,
> but that's cheating.)
>
> Jens
>
>
> > - Michael
> >
> >> On Jan 10, 2020, at 12:17 PM, Jens Maurer via SG5 <sg5_at_[hidden]
> <mailto:sg5_at_[hidden]>> wrote:
> >>
> >> In the interest of not surprising anyone, I intend to submit
> >> this to the pre-meeting mailing.
> >>
> >> Anyone on the current authors list that doesn't expressly
> >> approve being there will be moved to an "Acknowledgements"
> >> section before submission.
> >>
> >> Jens
> >>
> >>
> >> On 09/01/2020 22.06, Jens Maurer via SG5 wrote:
> >>> Hi!
> >>>
> >>> After today's teleconference, I couldn't resist, so
> >>> I created a draft TS for TM-light, mostly copying
> >>> from Victor's Google doc. See attached.
> >>>
> >>> The new part is in 8.8, where we decree implementation-defined
> >>> behavior when "bad" things are evaluated inside an atomic block.
> >>>
> >>> Possibly surprising changes vs. the status quo of the discussion:
> >>>
> >>> - constexpr functions only
> >>> (as explained in the teleconference, the compiler might not retain
> >>> other functions from the same translation unit)
> >>>
> >>> - throw-expressions are forbidden entirely
> >>> (Did we want to require support for throw/catch within the atomic
> >>> block? Seems more-than-minimal.)
> >>>
> >>> - Coroutines are forbidden entirely.
> >>> (I haven't seen talk about them vs. TM. Also, they have funny
> >>> control flow.)
> >>>
> >>> This would be in time to submit to the pre-Prague meeting,
> >>> for SG1 and EWG amusement there, if I get approval on this list
> >>> until Monday.
> >>>
> >>> I've added all participants to the authors list, please complain
> >>> if that's wrong.
> >>>
> >>> Jens
> >>>
> >>>
> >>
> >> --
> >> SG5 mailing list
> >> SG5_at_[hidden] <mailto:SG5_at_[hidden]>
> >> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
> >
>
> --
> SG5 mailing list
> SG5_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg5
>
Received on 2020-01-13 09:24:06