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 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. [1] Very shortly after morph, unlocking of the mutex is performed, which provides such a barrier, but there is still a very short window, which could cause a crash, *if* only the vtable change is seen by a parallel reader. [2] in kernel speak, i.e. C<sync> for ppc. 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>. leo
