Date: Thu, 09 Jun 2022 03:03:14 +0000
Also, volatile bool cannot be accessed by a signal handler, that is a race per the c++ standard?
-------- Original Message --------
On Jun 8, 2022, 23:02, Ryan P. Nicholl wrote:
> My understanding is that volatile applies not only to signal handlers but also debuggers and other programs writing to the variable. Is that wrong?
>
> When did the understanding of volatile change?
>
> -------- Original Message --------
> On Jun 8, 2022, 21:08, Thiago Macieira via Std-Proposals wrote:
>
>> On Wednesday, 8 June 2022 14:46:58 PDT Ryan P. Nicholl via Std-Proposals
>> wrote:
>>> Hello. I just wanted to point out a usage of volatile that I don't think
>>> should be deprecated. Namely, the use of volatile on a function argument.
>>
>> That's a clear one that should be deprecated. For architectures that pass
>> parameters in the stack, the address is practically arbitrary, is definitely on
>> the stack, and is usually exclusive to the callee. For architectures that pass
>> parameters in registers, there's simply no way to have a volatile register.
>>
>>> This may sound weird but it can be useful to create a parameter like
>>> 'volatile bool collect_debug_info = false' that gets passed down to
>>> functions that get called by the function. The function is called with it
>>> always false so if the function is inlined the compiler will elide all the
>>> instances of it being checked. Simply editing the variable in the debugger
>>> can be useful to collect information this way for a specific execution
>>> without having to do anything more complicated. I would therefore suggest
>>> this be either 1. un-deprecated, possibly as a defect report for C++20 or
>>> 2. a new keyword or attribute specifically for values that are intended to
>>> be changed in a debugger so that it still warns people misusing it for
>>> threading. I'm also unsure about the value of deprecating += and such, but
>>> it's definitely understandable.
>>
>> You're talking about optimisations, which means QoI. If you don't want the
>> compiler to elide that variable, then please talk to your compiler vendor.
>> None of your needs are related to the volatileness of said variable. And your
>> compiler is allowed to remove that volatile variable as you've described under
>> the "as-if" optimisation rule because it clearly cannot be observed by other
>> threads of execution or even signal handlers. The only reason you're getting
>> the behaviour you want is because when compilers see volatile, they usually
>> shut their brains off and stop optimising well.
>>
>> volatile variables only make sense if you're doing MMIO or similar
>> technologies where the acts of reading or writing are, themselves, observable.
>> Reading of stack, heap and regular global variables is not an observable act.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DPG Cloud Engineering
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
-------- Original Message --------
On Jun 8, 2022, 23:02, Ryan P. Nicholl wrote:
> My understanding is that volatile applies not only to signal handlers but also debuggers and other programs writing to the variable. Is that wrong?
>
> When did the understanding of volatile change?
>
> -------- Original Message --------
> On Jun 8, 2022, 21:08, Thiago Macieira via Std-Proposals wrote:
>
>> On Wednesday, 8 June 2022 14:46:58 PDT Ryan P. Nicholl via Std-Proposals
>> wrote:
>>> Hello. I just wanted to point out a usage of volatile that I don't think
>>> should be deprecated. Namely, the use of volatile on a function argument.
>>
>> That's a clear one that should be deprecated. For architectures that pass
>> parameters in the stack, the address is practically arbitrary, is definitely on
>> the stack, and is usually exclusive to the callee. For architectures that pass
>> parameters in registers, there's simply no way to have a volatile register.
>>
>>> This may sound weird but it can be useful to create a parameter like
>>> 'volatile bool collect_debug_info = false' that gets passed down to
>>> functions that get called by the function. The function is called with it
>>> always false so if the function is inlined the compiler will elide all the
>>> instances of it being checked. Simply editing the variable in the debugger
>>> can be useful to collect information this way for a specific execution
>>> without having to do anything more complicated. I would therefore suggest
>>> this be either 1. un-deprecated, possibly as a defect report for C++20 or
>>> 2. a new keyword or attribute specifically for values that are intended to
>>> be changed in a debugger so that it still warns people misusing it for
>>> threading. I'm also unsure about the value of deprecating += and such, but
>>> it's definitely understandable.
>>
>> You're talking about optimisations, which means QoI. If you don't want the
>> compiler to elide that variable, then please talk to your compiler vendor.
>> None of your needs are related to the volatileness of said variable. And your
>> compiler is allowed to remove that volatile variable as you've described under
>> the "as-if" optimisation rule because it clearly cannot be observed by other
>> threads of execution or even signal handlers. The only reason you're getting
>> the behaviour you want is because when compilers see volatile, they usually
>> shut their brains off and stop optimising well.
>>
>> volatile variables only make sense if you're doing MMIO or similar
>> technologies where the acts of reading or writing are, themselves, observable.
>> Reading of stack, heap and regular global variables is not an observable act.
>>
>> --
>> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>> Software Architect - Intel DPG Cloud Engineering
>>
>> --
>> Std-Proposals mailing list
>> Std-Proposals_at_[hidden]
>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
Received on 2022-06-09 03:03:21