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

-- 
• − − •/• −/• • −/• − • •/− • • •/•/− •/− • •/• •/− • • −/•/− •/• − −
•− •/− − •/− −/• −/• •/• − • •/• − • − • −/− • − •/− − −/− −//