What does volatile guarantee?
in [Java Help]
|
Prev: 64-bit JNI
Next: Problem with interface implementation
From: Lars Enderin on 15 Feb 2010 03:35 Roedy Green wrote: > On Sat, 13 Feb 2010 23:48:38 +0100, Lars Enderin > <lars.enderin(a)telia.com> wrote, quoted or indirectly quoted someone > who said : > >> Some text is rather faint, for example text rendered according to the >> CSS classes keyword, date, reviewed, statistic. It's readable, but very >> low contrast. My setup is shown by >> User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.7) >> Gecko/20100106 Ubuntu/9.10 (karmic) Firefox/3.5.7 GTB6 > > Hmm. I wonder if it has something to do with having anti-aliasing on > or off. Some fonts that are designed for anti-aliasing look spidery > thin when rendered without. No, the text is not thin, it's just faint, with low contrast, but readable. It looks almost transparent, which is what you asked about initially.
From: Andreas Leitgeb on 15 Feb 2010 04:32 Lew <noone(a)lewscanon.com> wrote: > 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. > > Then you missed the point. 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. > The matter of the existence or not of a shorthand combining operator is a red > herring. Java programming must really stink to you, with all those red herrings. 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. 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. 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.
From: Eric Sosman on 15 Feb 2010 10:40 On 2/14/2010 10:32 PM, Andreas Leitgeb wrote: > Lew <noone(a)lewscanon.com> wrote: >> Eric Sosman wrote in this thread on 2/12: >>>>> Before anybody whines^H^H^H^H^H^Hsuggests that making += >>>>> atomic would be easy, let him ponder >>>>> volatile int a,b,c,...,z; >>>>> a += b += c+= ... += z; >> > > On re-thought, even Eric's argument seems not too strong anymore: > First, z is read, > Then y is atomically increased by the previously read value. > Then x ... > ... > While e.g. "n" is increased, some other thread could modify "a" and "z". > Obviously, that is irrelevant to the current thread, which no longer > cares for "z"'s value, and not yet cared for "a"'s old value. > ... > Finally the resulting value of "b" would be added to the new value of "a". > > No ambiguities involved. It breaks Java's "left to right evaluation" rule, though. Whether that's important is for you as a language designer to decide. > So it's all just about whether "++","--","+=" and "-=" would be made > shorthands for what is already possible by the Atomic* classes. > The real reason boils down to that those atomic operations are still > slightly slower than the non-atomic ones, while the cases not caring > about atomicity by far outnumber the others. That's why I added > those "(not me!)"s. My impression (I'm by no means a hardware expert) is that the time penalty is considerably worse than "slight." It'll depend a lot on the nature of the hardware, though. -- Eric Sosman esosman(a)ieee-dot-org.invalid
From: Lew on 15 Feb 2010 12:23 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
From: Lew on 15 Feb 2010 15:05
Patricia Shanahan wrote: > How frequently does ++ appear in typical Java programs? Rather a lot, I should think. for ( int ix = 0; ix < limit; ++ix ) ... int count = 0; for ( Foo foo : foos ) { blahBlah(); ++count; } etc. Or did you mean specifically how often an atomic ++ for volatiles would be needed? I request clarification on your point about the branch not taken: > In addition to the obvious costs, consider the effect on branch > prediction. The interesting case is the ++ that does not need to be > atomic, the current use of ++. In those cases, the jneq will never be > taken. I should also think that the non-atomic ++ will not branch and loop but use the increment instruction of the host system. If there were an atomic ++ as well as the non-atomic, would the compiler have to generate different code depending on which one was in use? Was your point that that difference would complicate life for any attempt to create an atomic version of ++ that "knew" it was working with a volatile variable? If so, then the real question is how often an atomic ++ would be needed, and whether its frequency justifies a new semantic and more difficult compilation of the operator, vs. using the existing mechanisms for atomic incrementation. Given the issues you and Eric have elucidated for the implementation of an atomic ++ for volatile variables, its questionable benefit, and the existence of suitable ways to accomplish the same goal, it is clear that it is not a good idea. For those who disagree, you will very likely have to live with the disappointment of it never happening. -- Lew |