From: "Leopold Toetsch" <[EMAIL PROTECTED]> > Gordon Henriksen <[EMAIL PROTECTED]> wrote: > > On Friday, January 30, 2004, at 11:52 , Leopold Toetsch wrote: > >> + /* > >> + * if we morph to a string, first clear str_val > >> + * so that after changing the vtable a parallel > >> + * reader doesn't get a gargabe pointer > >> + */ > > > This is fine on a uniprocessor, but it's not enough on a multiprocessor. > > There, you need a sync instruction (on a PPC; equivalent elsewhere). > > Yep, that's right. As our PMC size isn't a power of 2, there is a small > chance that C<vtable> and C<str_val> are in different cache lines and
Even if the PMC size were a power of two, it woudn't necessitate C<vtable> and C<str_val> being in the same cache line. > only the change to the C<vtable> is seen by another CPU. > For ultimate correctness[1], we would need a C<rmb()> [2] instruction here. And the wmb() primitive there to ensure that the invalidate corresponding to reseting C<str_val> will appear on the bus ahead of the morphing vtable's invalidate. So the reading CPU can process these invalidates with rbm() in right order. Writing CPU | Reading CPU -----------------|------------------ lock() | reset C<str_val> | wbm() | morph() | unlock() | | rbm() | get C<str_val> > But I don't see a big problem here, we could just configure and insert a > C<smp_rmb()> from F<$linux_kernel_src/include/asm-$arch/system.h>. You're lucky, linux folks. > leo 0x4C56