Vladimir Lipsky <[EMAIL PROTECTED]> wrote: > From: "Leopold Toetsch" <[EMAIL PROTECTED]> >> >> 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. Aligned pool memory is given :) >> 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. That isn't necessary. One rmb() after resetting C<str_val> ought to be enough. It ensures that in all cases the other CPU reads str_val as NULL. If the vtable is still pointing to the PerlInt vtable, its a user problem (reading a variable that is changed in a parallel thread). If the vtable is pointing already to PerlString the second CPU gets a NULL string (which is handled in string.c) or finally gets the correct result. >> 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. Yep. But don't care: i386 doesn't need these memory barriers. > 0x4C56 leo
