Re: [9fans] waitfree

[erik quanstrom <quanstro@quanstro.net>]

> I can't think of any reason it should be implemented in that way as
> long as the cache protocol has a total order (which it must given that
> the μops that generate the cache coherency protocol traffic have a
> total order), a state transition from X to E can be done in a bounded
> number of cycles.

my understanding is that in this context this only means that different
processors see the same order.  it doesn't say anything about fairness.

> The read function will try to find a value for addr in cache, then
> from memory. If the LOCK-prefixed instruction's decomposed read μop
> results in this behavior, a RFO miss can and will happen multiple
> times. This will stall the pipeline for multiple memory lookups. You
> can detect this with pipeline stall performance counters that will be
> measurably (with significance) higher on the starved threads.
> Otherwise, the pipeline stall counter should closely match the RFO
> miss and cache miss counters.

yes.

> For ainc() specifically, unless it was inlined (which ISTR the Plan 9
> C compilers don't do, but you'd know that way better than me), I can't
> imagine that screwing things up. The MOV's can't be LOCK-prepended
> anyway (nor do they deal with memory), and this gives other processors
> time to do cache coherency traffic.

it doesn't matter if this is hard to do.  if it is possible under any circumstances,
with any protcol-adhering implementation, then the assertion that amd64
lock is wait-free is false.

- erik