Date: Fri, 12 Feb 2021 11:26:30 -0000
Please also note that there is a paper in review that follows through on removal of previously deprecated items. Removal of deprecated volatile types is addressed here:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2139r2.html#3.5
It is my understanding from Alisdair Meredith (author of the paper and fellow Bloomberg colleague) that "[t]here was consensus to remove increment and decrement on volatile, compound assignment on volatile, volatile return types, and volatile in structured bindings, although most votes were just weakly in favor. The support for removing volatile on function parameters was split evenly on weakly in favor or neutral."
He would be interested in syncing up to understand where we are concerning this. It is not clear to me whether one would un-deprecate as part of this consolidated paper.
--Jeffrey
From: sg14_at_[hidden] At: 02/11/21 19:29:17To: sg14_at_[hidden], wouter.vanooijen_at_[hidden]
Cc: paulbendixen_at_gmail.com
Subject: Re: [SG14] Challenging the deprecation of volatile compound statements
Ok so I tried
This is absolutely the first draft of a draft, or what i like to call
the braindump edition. Formatting is horrible and wording could
probably also be improved.
Please let me know what you think and where it could be improved,
especially if there are things I have omitted.
If anyone would like to collaborate on this the tex should be public
at https://gitlab.com/paulbendixen/dedeprecate
Two questions:
1) I will probably need a number for this, how do I get that?
2) The standard says that simple assignments to volatile qualified
types are deprecated, does this mean that you cannot assign a volatile
int?
Best
Paul
Den tor. 11. feb. 2021 kl. 20.57 skrev Tjernstrom, Staffan via SG14
<sg14_at_[hidden]>:
>
> >On 11/02/2021 09.08, Paul M. Bendixen via SG14 wrote:
> >> After a (long overdue) complete read of both r0 and r4 of p1152 i have
> >> come to a few conclusions:
> >>
> >> 1. While the motivation in r0 is quite thorough, it fails to convey
> >> the dangers of using the compound volatile operations in higher level
> >> highly threaded code that was alluded to in tonight's meeting.
> >> If anyone could enlighten me further in this regard I'd be much
obliged.
>
>
> >Jens:
> >As far as I understand, the idea is that
>
> > x |= 5;
>
> >with volatile "x" might be misconstrued to actually be a thread-atomic
operation (look, "x" appears only once).
>
> >This confusion is less likely with the spelling "x = x | 5".
>
> This is essentially my experience. There are a few factors that lead into why
this is particularly an issue with "volatile x".
>
> In a multi-langauge stack, it's not uncommon (I see cases about 1-2 times a
year) that those programming in the upper layers on occasion cause extra
threads to be created in the lower levels, turnig what was designed as
single-threaded code into multi-threaded such. When tracking down the chaos
that invariably ensues, it's very easy to mis-read the concatenated statement
as something akin-to-single-operation - the investigators mind is usually on
oither issues at the time.
>
> Why is volatile particularly vunerable here? In a multi-language stack, the
IPC mechanisms commonly cannot make use of atomics, either due to
compiler/interpreter limitations and/or differences in the memory models. So
things like queue counters, etc, end up being volatile (being capable of being
manipulated outside of the C++ abstract machine).
>
> Basically, either the "x |= 5" or "x = x | 5" versions are a bug in our code
if they occur. More correctly we try to use something like
>
> volatile int x;
> std::atomic<int> temp_store;
>
> temp_store = x;
> temp_store |= 5;
> x = temp_store;
>
> That is to say, doing the manipulation outside of the volatile sphere.
>
> In fairness to the embedded side, it is very rare indeed that our stack would
use the bitmask operations on volatiles in this use-case. The mathematical
operations are by far the common use-case. In the interest of compromise it
would be no big deal to only un-deprecate the bitwise compact operators for
volatile - Thanks Jens for that idea..
>
> > 2. The changes that Wouter and others (myself included) found
> > frightening were mostly neglected in R0: "This is a departure from C
> > which breaks source compatibility (once removed), but maintains ABI
> > compatibility."
> > And even though the committee was heard on the question, the
> > question was before SG1 and EWG ( from r0 -> r1 changelog), not
> > necessarily parts of the committee that are affected by the proposed
> > changes (compound operations).
>
> > Finally, on a more introspective note, this leaves me with some doubts
> > regarding what we are doing here.
> > This paper has its r0 date in 2018. I have been following this group
> > since at least then and cannot remember it ever being mentioned before
> > being part of the standard.
>
> I think the procedural issue here is that the paper was reviewed primarily
from a concurrency angle (thus, in SG1), with the understanding that "volatile"
was/is occasionally (and incorrectly) used to express thread-atomic operations.
>
> The paper was never brought before SG14, and nobody thought about the
"embedded/device driver" angle at the time, including the amplified C
compatibility issues. Sorry about that.
>
> My view: Just write a short paper so that we can reintroduce compound
assignment. Maybe you just need |= and &= for the device drivers, but not +=
and *= and /= etc, so that we can leave the latter ones deprecated for volatile
operands?
>
> Jens
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p2139r2.html#3.5
It is my understanding from Alisdair Meredith (author of the paper and fellow Bloomberg colleague) that "[t]here was consensus to remove increment and decrement on volatile, compound assignment on volatile, volatile return types, and volatile in structured bindings, although most votes were just weakly in favor. The support for removing volatile on function parameters was split evenly on weakly in favor or neutral."
He would be interested in syncing up to understand where we are concerning this. It is not clear to me whether one would un-deprecate as part of this consolidated paper.
--Jeffrey
From: sg14_at_[hidden] At: 02/11/21 19:29:17To: sg14_at_[hidden], wouter.vanooijen_at_[hidden]
Cc: paulbendixen_at_gmail.com
Subject: Re: [SG14] Challenging the deprecation of volatile compound statements
Ok so I tried
This is absolutely the first draft of a draft, or what i like to call
the braindump edition. Formatting is horrible and wording could
probably also be improved.
Please let me know what you think and where it could be improved,
especially if there are things I have omitted.
If anyone would like to collaborate on this the tex should be public
at https://gitlab.com/paulbendixen/dedeprecate
Two questions:
1) I will probably need a number for this, how do I get that?
2) The standard says that simple assignments to volatile qualified
types are deprecated, does this mean that you cannot assign a volatile
int?
Best
Paul
Den tor. 11. feb. 2021 kl. 20.57 skrev Tjernstrom, Staffan via SG14
<sg14_at_[hidden]>:
>
> >On 11/02/2021 09.08, Paul M. Bendixen via SG14 wrote:
> >> After a (long overdue) complete read of both r0 and r4 of p1152 i have
> >> come to a few conclusions:
> >>
> >> 1. While the motivation in r0 is quite thorough, it fails to convey
> >> the dangers of using the compound volatile operations in higher level
> >> highly threaded code that was alluded to in tonight's meeting.
> >> If anyone could enlighten me further in this regard I'd be much
obliged.
>
>
> >Jens:
> >As far as I understand, the idea is that
>
> > x |= 5;
>
> >with volatile "x" might be misconstrued to actually be a thread-atomic
operation (look, "x" appears only once).
>
> >This confusion is less likely with the spelling "x = x | 5".
>
> This is essentially my experience. There are a few factors that lead into why
this is particularly an issue with "volatile x".
>
> In a multi-langauge stack, it's not uncommon (I see cases about 1-2 times a
year) that those programming in the upper layers on occasion cause extra
threads to be created in the lower levels, turnig what was designed as
single-threaded code into multi-threaded such. When tracking down the chaos
that invariably ensues, it's very easy to mis-read the concatenated statement
as something akin-to-single-operation - the investigators mind is usually on
oither issues at the time.
>
> Why is volatile particularly vunerable here? In a multi-language stack, the
IPC mechanisms commonly cannot make use of atomics, either due to
compiler/interpreter limitations and/or differences in the memory models. So
things like queue counters, etc, end up being volatile (being capable of being
manipulated outside of the C++ abstract machine).
>
> Basically, either the "x |= 5" or "x = x | 5" versions are a bug in our code
if they occur. More correctly we try to use something like
>
> volatile int x;
> std::atomic<int> temp_store;
>
> temp_store = x;
> temp_store |= 5;
> x = temp_store;
>
> That is to say, doing the manipulation outside of the volatile sphere.
>
> In fairness to the embedded side, it is very rare indeed that our stack would
use the bitmask operations on volatiles in this use-case. The mathematical
operations are by far the common use-case. In the interest of compromise it
would be no big deal to only un-deprecate the bitwise compact operators for
volatile - Thanks Jens for that idea..
>
> > 2. The changes that Wouter and others (myself included) found
> > frightening were mostly neglected in R0: "This is a departure from C
> > which breaks source compatibility (once removed), but maintains ABI
> > compatibility."
> > And even though the committee was heard on the question, the
> > question was before SG1 and EWG ( from r0 -> r1 changelog), not
> > necessarily parts of the committee that are affected by the proposed
> > changes (compound operations).
>
> > Finally, on a more introspective note, this leaves me with some doubts
> > regarding what we are doing here.
> > This paper has its r0 date in 2018. I have been following this group
> > since at least then and cannot remember it ever being mentioned before
> > being part of the standard.
>
> I think the procedural issue here is that the paper was reviewed primarily
from a concurrency angle (thus, in SG1), with the understanding that "volatile"
was/is occasionally (and incorrectly) used to express thread-atomic operations.
>
> The paper was never brought before SG14, and nobody thought about the
"embedded/device driver" angle at the time, including the amplified C
compatibility issues. Sorry about that.
>
> My view: Just write a short paper so that we can reintroduce compound
assignment. Maybe you just need |= and &= for the device drivers, but not +=
and *= and /= etc, so that we can leave the latter ones deprecated for volatile
operands?
>
> Jens
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>
> ________________________________
>
> IMPORTANT: The information contained in this email and/or its attachments is
confidential. If you are not the intended recipient, please notify the sender
immediately by reply and immediately delete this message and all its
attachments. Any review, use, reproduction, disclosure or dissemination of this
message or any attachment by an unintended recipient is strictly prohibited.
Neither this message nor any attachment is intended as or should be construed
as an offer, solicitation or recommendation to buy or sell any security or
other financial instrument. Neither the sender, his or her employer nor any of
their respective affiliates makes any warranties as to the completeness or
accuracy of any of the information contained herein or that this message or any
of its attachments is free of viruses.
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
-- • − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − − •− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −// ---------------------------- _______________________________________________ SG14 mailing list SG14_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/sg14
Received on 2021-02-12 05:26:33