On Thu, Feb 11, 2021 at 7:29 PM Paul M. Bendixen via SG14 <
sg14_at_[hidden]> wrote:

> 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?
>
No. There's an "unless". The wording says, for example, that doing:
int y = (x = 5);
for a volatile int x is deprecated.

not that
x = 5;
is deprecated.


>
> 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
>