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
