|
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 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.