On 22 Nov, 2014, at 11:56 , Masao Uebayashi <uebay...@gmail.com> wrote: > On Sat, Nov 22, 2014 at 11:49 AM, Masao Uebayashi <uebay...@gmail.com> wrote: >> It is users' choice whether using fast-changing values as a key or >> not, but if you decide to change values visible by pserialize(9) >> readers, you'll end up with ensuring memory order. It is your choice, >> but beyond pserialize(9)'s responsibility. > > Correction: changing values can be read by volatile. No memory > barrier is needed if there's no memory ordering constraint.
Using volatile is very frequently a bug. You have two closely related problems to deal with on a multiprocessor, that the compiler may reorder or eliminate memory accesses and that the processor cache hardware may reorder or eliminate memory accesses. If you attempt to fix a problem with volatile (and you seem to realize there is a problem if you are using volatile to fix it) you may fix the compiler problem but do nothing to fix the cache hardware problem. A barrier fixes both at the same time. Dennis Ferguson
