Avi Kivity wrote: > On 10/06/2009 09:40 PM, Gregory Haskins wrote: >> Thinking about this some more over lunch, I think we (Avi and I) might >> both be wrong (and David is right). Avi is right that we don't need >> rmb() or barrier() for the reasons already stated, but I think David is >> right that we need an smp_mb() to ensure the cpu doesn't do the >> reordering. Otherwise a different cpu could invalidate the memory if it >> reuses the freed memory in the meantime, iiuc. IOW: its not a compiler >> issue but a cpu issue. >> >> Or am I still confused? >> >> > > The sequence of operations is: > > v = p->v; > f(); > // rmb() ? > g(v); > > You are worried that the compiler
No > or cpu will fetch p->v after f() has executed? Yes. > The compiler may not, since it can't tell whether f() might > change p->v. Right, you were correct to say my barrier() suggestion was wrong. > If f() can cause another agent to write to p (by freeing > it to a global list, for example), then it is its responsibility to > issue the smp_rmb(), otherwise no calculation that took place before f() > and accessed p is safe. > IOW: David is right. You need a cpu-barrier one way or the other. We can either allow ->release() to imply one (and probably document it that way, like we did for slow-work), or we can be explicit. I chose to be explicit since it is kind of self-documenting, and there is no need to be worried about performance since the release is slow-path. OTOH: If you feel strongly about it, we can take it out, knowing that most anything the properly invalidates the memory will likely include an implicit barrier of some kind. Kind Regards, -Greg
signature.asc
Description: OpenPGP digital signature
