• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

volatile on Windows

 
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I try several examples (from Effective Java 2, Item 66, StopThread, and from Paul Hyde "Java Thread Programming", page 172, Volatile class). Those code fragments suppose to demonstrate that if you don't declare variable as volatile, the value can be (will be in specially constructed examples) different for different threads. (Visibility, compiler optimization, JIT, etc.)

However, on Windows XP (where I am experimenting) with java 1.6.0_25 (-b06) all those examples fail to demonstrate that effect. All thread see the same value for non-volatile variables.

So, I wonder, how to build example on Windows to observe effect of declaring variable volatile? Does anybody has such an example?

Thanks

Alexey
 
Saloon Keeper
Posts: 15484
363
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello Alexey, welcome to CodeRanch.

Simply said, you can't write a program which demonstrates the effect. That's the point. Without the volatile keyword, the value of a variable gets written through to main memory at the machine's discretion. Java can make no guarantees regarding when this happens, so you also can't write a program that shows the difference.
 
Alexey Yakubovich
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Stephan,

Thanks for quick response. Well, I see what you mean. However Mr. Joshua Bloch said in EJ: "On my machine (that) program never terminates." I wonder how it happens ... Anyway, thanks again.I will try on Linux, try compile not with Eclipse incremental compiler, but with javac ... If I will figure out how to get that effect, I will publish it on Ranch.
 
Ranch Hand
Posts: 443
3
Eclipse IDE C++ Java
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
... and I'll begin ;-)

1) Windows / intel etc present a "strong (ish) memory model" , i.e. they rarely present caching issues (intel some cache sharing tech ;-) ), though they are still possible and all the documentation says they reserve the right to get weaker i.e. in theory new chip / OS version come out all bets off they gave you volatile and memory barriers your fault for not using them ... lol (they have their backs covered, I think MSDN used to say Intels Itanium family was weaker and I think there was an AMD chip that had an issue round this), regardless of what the chip and OS present the JVM only guarantees a weak memory model as it will add hotspot compiler type issues into the mix...

2) Volatile isn't just about caching its about "happens before ordering" which gives our variables visibility ...

I can't see the example you're discussing but I guess (complete stab in the dark) its this one where stopped is none volatile the following optimisation is legal. These kind of problems are unfortunately very hard to provoke (and the act of observing can sometimes fix this issue e.g. debuggers, System.out etc etc ) which makes testing a nightmare, the question being how would you unit test such code ...

Might be this java optimisation your after (maybe ;-) , I don't have the second edition of Effective Java )



If you were teaching volatile for instance I would consider downloading terracotta which allows your java code to run across multiple JVMs (normally different machines but you can use the same one) , this would demonstrate the issue every time i.e. volatile / not which is why I've always been interested to see if I could do unit tests that worked for the scenario I out lined.

If that's not the issue, you'll have to forward the section of the book .. lol

 
Alexey Yakubovich
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Chris,

Thanks for sharing. I also want to share some finding, though pretty predictable.
So, yes, it's this piece of code from Effective Java. I don't copy it here, everyone can find it in Item 66. What i found out, if you run on Windows with JVM option -server, it works as promised! Second thread never notices the change of "stopped" made in main thread. Interestingly enough, this piece of code can be useful to find out when java standard API uses synchronized. E.g. unexpected (for me): if you put inside run() loop a line like Integer iObj = new Integer(), the "stopped" becomes visible in thread! Like if you use System.out.print(). But Object obj = new Object() does not produce that effect.
Another example where non-volatile suppose to break, from the Paul Hyde "Java Thread Programming" book (p.122) seems does not work for 1.5 and later and can't be completely fixed, because in 1.5 one volatile class member can change semantics of others non-volatile members. However, if remove volatile declaration from all class members completely, it's getting really interesting, the example shows (again and in different way) that non-volatile members are not visible.
I know it all of a little practical interest, and I stop now that thread. But interesting ... like in J. Bloch puzzles. And no, I am not teaching, except only myself
 
Ranch Hand
Posts: 300
Eclipse IDE Firefox Browser Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Hi Alexey,

Based on my experience anything related to concurrency e.g. synchronized or volatile is hard to reproduce. I know several incident where program is running fine under test environment but doesn't able to run properly on production due to load. so best way to reproduce concurrency bug or effect or scenario is run a load test but again its depends upon configuration of machine, number of register, how machine is caching values etc. concurrency bug will more likely to come on a truly multi-threaded environment e.g. with multiple core. any way keep us updated with your finding.

Javin
 
Rancher
Posts: 43081
77
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Seeing the words "volatile" and "Windows" together as if it's something that needs to be explained is priceless.
 
reply
    Bookmark Topic Watch Topic
  • New Topic