× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On 09/26/2002 at 11:57:23 AM, java400-l-admin@midrange.com wrote:
I read something that made me think that declaring a variable as
volatile forces private variables to be reconciled on access, thereby
getting
around the weakly consistent hardware issue. I also read something that
makes
me wonder if volatile is even implemented in all JVMs. It would seem
that if volatile were implemented you could use that fact to force hardware
consistency. Or is this just another trap?
--- end of excerpt ---

I too have heard (in one of the JavaOne multi-threading foils I think) that
many JVMs don't implement volatile semantics correctly (but can't quote).

I'm not very familiar with the exact specified behavior of volatile, but my
understanding is that it (specification) only really guarantees visibility
with regard to
ordering of loads and stores with regard to OTHER volatile variables.

i.e. This code doesn't say anything about the visibility to other threads
with regard
to b (or whether b will be stored before or after volatile).
      volatile int a;
      int b;
      a = 1;
      b = 2;
Can anyone confirm or deny?

I've always viewed it as a trap, mostly due to the complexity.
If you try to be really tricky and avoid synchronization, there's a very
good chance you'll just do it wrong. Instead, I've taken a simpler more
sure approach where I modify my design so the shared data (and/or
duration of sharing) was minimized or eliminated, or, I just did the
required synchronization.


"The stuff we call "software" is not like anything that human society
  is used to thinking about. Software is something like a machine, and
  something like mathematics, and something like language, and
  something like thought, and art, and information...
  but software is not in fact any of those other things."
Bruce Sterling - The Hacker Crackdown

Fred A. Kulack - IBM eServer iSeries - Enterprise Application Solutions
ERP, Java DB2 access, Jdbc, JTA, etc...
IBM in Rochester, MN  (Phone: 507.253.5982   T/L 553-5982)
mailto:kulack@us.ibm.com   Personal: mailto:kulack@magnaspeed.net
AIM Home:FKulack  AIM Work:FKulackWrk
MSN Work: fakulack@hotmail.com




As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.