Thank you very much for bringing this to my /our attention. This will
certainly influence how much we need to make other parts of the committee
aware of this whether removal is to be slated for 23 or 26.
/Paul

fre. 12. feb. 2021 12.59 skrev Jeffrey Olkin (BLOOMBERG/ 120 PARK) via SG14
<sg14_at_[hidden]>:

> 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:17
> To: sg14_at_[hidden], wouter.vanooijen_at_[hidden]
> Cc: paulbendixen_at_[hidden]
> 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
>
>
> _______________________________________________
> SG14 mailing list
> SG14_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg14
>