Date: Wed, 29 Apr 2020 16:30:28 -0700
On Wed, Apr 29, 2020 at 4:26 PM Patrice Roy <patricer_at_[hidden]> wrote:
> The need for a mechanism to ensure some operations are actually
> performed, under whatever name we use, seems clear to me and has
> been a recurring topic over the years. The work done by JF on
> deprecating some uses of volatile also show (if we needed this to
> be shown) that volatile lacked love... and, more formally, that
> it was not sufficiently specified.
>
> John Regehr has suggested in the past that, should be rethink
> the volatile-related parts of the standard, one interesting avenue
> could be to express volatile in terms of operations instead of
> expressing them in terms of objects. If we took that path for
> this mechanism (as was discussed in Cologne, from the paper
> history; voting at 4 5 4 0 0 seems encouraging), we could start
> to address the problems of adapting the abstract machine in terms
> of a smaller subset of functions that impact the way we express
> "as if", using some function that are not "as if" but have to be
> taken literally by the compiler. This might localize the impact
> of such changes to the sections where we discuss observable
> behavior and fit in with std::observable.
>
> Should we invest efforts in re-expressing aspects of the abstract
> machine that discuss volatile in terms of volatile loads and
> stores, and build facilities such as p1315 and n4534 from there?
>
I believe we should: wg21.link/P1382
Paul will likely need help on the wording aspects.
Le mar. 28 avr. 2020 à 17:55, Jens Maurer via SG12 <sg12_at_[hidden]>
> a écrit :
>
>> On 28/04/2020 23.21, Miguel Ojeda wrote:
>> > # Jens Maurer
>> >
>> >> In order to solve these issues satisfactorily, we probably need a
>> research effort approximately on the same level as improving our memory
>> model for multi-threaded operations. This was a multi-year effort involving
>> top-notch experts in the trade.
>> >
>> > Perhaps (I don't disagree with you on this, as you know), but the
>> > multi-threaded memory model is a good example of how something can
>> > work in practice, given programs using it were a thing decades before
>> > the memory model was formalized into the standard. Of course, it was
>> > not in the standard, but `memset_s` provides the example of something
>> > useful in the standard without being fully formal yet.
>>
>> There's a bit of ambiguity here regarding the phrase "the standard".
>> My understanding is we're talking about the C++ standard, but
>> memset_s was never in that standard.
>>
>> Jens
>> _______________________________________________
>> SG12 mailing list
>> SG12_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
>> Link to this post: http://lists.isocpp.org/sg12/2020/04/0878.php
>>
>
> The need for a mechanism to ensure some operations are actually
> performed, under whatever name we use, seems clear to me and has
> been a recurring topic over the years. The work done by JF on
> deprecating some uses of volatile also show (if we needed this to
> be shown) that volatile lacked love... and, more formally, that
> it was not sufficiently specified.
>
> John Regehr has suggested in the past that, should be rethink
> the volatile-related parts of the standard, one interesting avenue
> could be to express volatile in terms of operations instead of
> expressing them in terms of objects. If we took that path for
> this mechanism (as was discussed in Cologne, from the paper
> history; voting at 4 5 4 0 0 seems encouraging), we could start
> to address the problems of adapting the abstract machine in terms
> of a smaller subset of functions that impact the way we express
> "as if", using some function that are not "as if" but have to be
> taken literally by the compiler. This might localize the impact
> of such changes to the sections where we discuss observable
> behavior and fit in with std::observable.
>
> Should we invest efforts in re-expressing aspects of the abstract
> machine that discuss volatile in terms of volatile loads and
> stores, and build facilities such as p1315 and n4534 from there?
>
I believe we should: wg21.link/P1382
Paul will likely need help on the wording aspects.
Le mar. 28 avr. 2020 à 17:55, Jens Maurer via SG12 <sg12_at_[hidden]>
> a écrit :
>
>> On 28/04/2020 23.21, Miguel Ojeda wrote:
>> > # Jens Maurer
>> >
>> >> In order to solve these issues satisfactorily, we probably need a
>> research effort approximately on the same level as improving our memory
>> model for multi-threaded operations. This was a multi-year effort involving
>> top-notch experts in the trade.
>> >
>> > Perhaps (I don't disagree with you on this, as you know), but the
>> > multi-threaded memory model is a good example of how something can
>> > work in practice, given programs using it were a thing decades before
>> > the memory model was formalized into the standard. Of course, it was
>> > not in the standard, but `memset_s` provides the example of something
>> > useful in the standard without being fully formal yet.
>>
>> There's a bit of ambiguity here regarding the phrase "the standard".
>> My understanding is we're talking about the C++ standard, but
>> memset_s was never in that standard.
>>
>> Jens
>> _______________________________________________
>> SG12 mailing list
>> SG12_at_[hidden]
>> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/sg12
>> Link to this post: http://lists.isocpp.org/sg12/2020/04/0878.php
>>
>
Received on 2020-04-29 18:33:40