Date: Thu, 30 Apr 2020 10:33:56 -0700
On Wed, 29 Apr 2020, 16:26 Patrice Roy via SG12, <sg12_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.
>
We already did that, three years ago. See P0612R0, resolving NB comment CH
2 from the C++17 CD.
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?
>
>
>
>
> 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
>>
> _______________________________________________
> 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/0879.php
>
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.
>
We already did that, three years ago. See P0612R0, resolving NB comment CH
2 from the C++17 CD.
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?
>
>
>
>
> 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
>>
> _______________________________________________
> 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/0879.php
>
Received on 2020-04-30 12:37:08