On Thu, Aug 21, 2008 at 01:02:48PM +0200, Peter Zijlstra wrote:On Thu, 2008-08-21 at 12:57 +0200, Stefan Richter wrote:Peter Zijlstra wrote:Sure, but volatile isn't a replacement for memory barriers.On Wed, 2008-08-20 at 20:50 -0600, jmerkey@xxxxxxxxxxxxxxxxxxxxx wrote:I hope Jeff didn't try mere barrier()s only. smp_wmb() and smp_rmb()
volatiles left in the code due to the previously statedCan you provide explicit detail?
(and still present) severe breakage of the GNU compiler with SMP shared data. most of the barrier() functions are just plain broken
and do not result in proper compiler behavior in this tree.
By using barrier() the compiler should clobber all its memory and
registers therefore forcing a write/reload of the variable.
are the more relevant barrier variants for mdb, from what I remember
when I last looked at it.
Let's face it, the C standard does not support concurrency, so we are
all in a state of sin in any case, forced to rely on combinations of
gcc-specific non-standard language extensions and assembly language.
Could be worse!!!