Date: Thu, 30 Apr 2020 14:17:07 -0400
Thanks, I had missed it!
Le jeu. 30 avr. 2020 à 13:34, Richard Smith <richardsmith_at_[hidden]> a
écrit :
> 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
>>
>
Le jeu. 30 avr. 2020 à 13:34, Richard Smith <richardsmith_at_[hidden]> a
écrit :
> 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
>>
>
Received on 2020-04-30 13:20:36