Re: What does volatile guarantee?
Andreas Leitgeb wrote:
Afterall, making "++" and "--" and the "op="s atomic just for volatile
variables wouldn't seem all that wrong to me. As there is no
"Math.sqrt="
operator your other snippet seems quite irrelevant.
Lew wrote:
Then you missed the point.
Andreas Leitgeb wrote:
I have, w.r.t the spectrum.
You have, w.r.t certain points of the spectrum lending themselves
to a boundary line more than others, and not less than the current.
No. You just restated my point - that there is a spectrum, at one end already
implementing the atomicity, at the other end being ridiculous to implement
atomicity, and in between some points lend themselves to it more than others.
That's exactly what I was saying. Thank you for clarifying it.
The shorthand combining operators already differ from their explicit
a = a <op> b variants. (especially for array-elements and fields
of non-trivially obtained objects)
Adding their atomicity for volatiles wouldn't exactly wreck the whole
paradigm.
I never said they would, only that they didn't need to be changed.
There is a cost to changing a language, and it's cumulative. It's like
radiation or acetominophen - small doses are ok, but repeatedly over time they
add up to a toxic level. Changes should be conservative, not eager.
For consistency, however, *all* of them would have to be atomic then,
including e.g. /=, >>>= ... which do not even have counterparts in
the Atomic* classes so far.
Thank goodness for the other synchronization techniques, then.
I'm not really proposing them, just arguing that they wouldn't be *bad*.
I make no claim, that they'd be anything more than just a convenience.
Sometimes, conveniences happen.
And because of the aforementioned cumulative toxicity, they should be resisted
unless they can be shown to have minimal or negligible impact and important
benefit. Eric has shown that the changes for the combined operators will not
be minimal, and no one has argued that the benefit is important. Ergo, don't
do it.
--
Lew