Re: Why does membar_consumer() do anything on x86_64?

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

On 11.11.2011 09:59, YAMAMOTO Takashi wrote:
> hi,
> 
> what's the status of this topic?

Can't remember. I think it should be fine to remove the lock from
membar_consumer() (although I am not the only one who can decide on this).

HOWEVER, if we remove the lock, I am not certain that member_enter()
being an alias for membar_consumer() will still be valid for x86:

  membar_enter()

    Any store preceeding membar_enter() will reach global visibility
    before all loads and stores following it.

Given the rule above for x86, membar_enter() _must_ ensure that older
stores have to reach global visibility before any subsequent load, and
here a lock is needed.

The Xen rings' load/store ordering are "protected" by Xen's memory
barriers (xen_rmb and such), which are aliases for x86 lfence/sfence.
AFAICT membar_ops(9) are not concerned for Xen.

IMHO Xen rings' are the worst situation you could get into with x86
"loads may be reordered against older stores to different locations";
rings contain their own indexes in addition to requests/responses, and
their content is accessed concurrently without any locks, coherency
being enforced only by xen_*mb() barriers.

-- 
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost