Date: Thu, 11 Feb 2021 20:32:32 +0100
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.
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".
> 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
> 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.
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".
> 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
Received on 2021-02-11 13:32:41