Hi, What you're hitting is the internals of how processors share information.
Bert Miemietz wrote: > Hallo Darryl, > > thanks a lot for your explanations. They match exactly what I was used to. > But when working through the multithreading manual I got a little bit nervous > about the explanations since what is written there about multiprocessors > and relaxed memory order would have a serious effect on the code to write. > There are two sources contradicting your/our/my concept: > > 1.) Multithreaded Programming Guide (Sept. 2008, Page 240) > "programmers must be careful to use locks around all global or shared data." > This is explained by store buffers of one processor that are not necessarily > flushed and hence modified data not being visible to other processors > (threads). > > 2.) The Sun MT-FAQ (95114-001) > Does the C keyword "volatile" cause the store buffer to flush ? > ... > The answer: writing to a volatile-qualified type object does not cause a > store buffer flush. > These are correct. When you store data it does not necessarily mean that other processors can see that information. If processor A writes to variable B, then that store goes through a store queue, then gets written to cache on Processor A, eventually, that cacheline will get flushed to memory. The volatile keyword ensures that the store occurs, but does not ensure that the data is flushed to memory. > This is exact the contrary to your explanation > "When you declare a variable to be volatile it ensures that the compiler > always loads that variable from memory and immediately stores it back to > memory after any operation on it." The volatile keyword ensures that the variable is not held in a register, and is stored back to memory as quickly as possible. However, I'm using "stored to memory" as shorthand for placed into the store queue, then put into cache, then flushed to memory at some point in the future. > > Since conforming and portable code is very much an issue for our current > project we were a little bit concerned. Perhaps things could be made a > little bit clearer in the manuals (provided we are not too dumb to understand > them at all). > The topic you're really interested in is memory bars (membars) on SPARC or memory fences (mfence) on x86. Basically on SPARC, which uses total store order (TSO), you don't need them in all but the most exceptional circumstances. On x86 you might need them because it uses a weaker consistency model. Take a look at Dave Dice's blog post on this topic: http://blogs.sun.com/dave/entry/java_memory_model_concerns_on I have some more pointers here: http://blogs.sun.com/d/entry/when_to_use_membars Regards, Darryl. > Thanks for your help! > > b.m. -- Darryl Gove Compiler Performance Engineering Blog : http://blogs.sun.com/d/ Books: http://www.sun.com/books/catalog/solaris_app_programming.xml http://my.safaribooksonline.com/0595352510
