[AMO] Atomic memory operations register a reservation on the memory address?

[Xavier]

Dear All,

 

I saw the recommanded the spinlock implementation by using amoswap instructions.

Would like to understand will atomic memory operations register a reservation or not?

• If the AMO operation registers a reservation, the store part might not write data on the address if exclusive monitor fail. For current arch_spin_unlock impl, the lock value won't be updated in the case.
  
• If the AMO operation doesn't register a reservation, it's possible 2 harts both enter the critical section by a certain memory order.
  

 

Thanks,

Xavier

[Samuel Falvo II]

On Tue, Feb 6, 2018 at 6:01 PM, Xavier <csh9...@gmail.com> wrote:
> Would like to understand will atomic memory operations register a
> reservation or not?

No.

> If the AMO operation doesn't register a reservation, it's possible 2 harts
> both enter the critical section by a certain memory order.

Also no.

The way AMO instructions work is they produce a special bus
transaction which the memory system recognizes. Either an explicit
LOCK signal is asserted during the entire read-modify-write operation,
OR, a special command is issued to the memory controller which takes
it upon itself (note: NOT the CPU!) to both read and write-back a
modified value (depending on the nature of the instruction causing
it).

If the memory controller uses TileLink, for example, it can receive a
special transaction that causes the memory controller itself to read
the current value and write the requested value, atomically. Even if
two harts execute an amoswap instruction at *exactly* the same time,
the memory controller *must* decide which *one* to execute first. In
this way, AMO instructions always execute sequentially and atomically,
even across harts, as viewed by a particular memory slave.

Hope this helps clear up any confusion.

--
Samuel A. Falvo II

[Xavier]

Hello Samuel,

Thank you :) The explanation clarifies my confusion.

However, some bus protocol(ex. AXI4) doesn't support the lock type transaction. 

The kind of system might not be able to realize the atomic instruction.

Best Regards,

Xavier 

Samuel Falvo II於 2018年2月7日星期三 UTC+8上午10時28分50秒寫道：

[Paul Miranda]

There is this line from the riscv-spec: "A simple microarchitecture can implement AMOs using the LR/SC primitives."

Which leads me to believe it would be acceptable to implement the atomics using reservation-style bus hardware with retry.

Of course the newer AXI5 supports true atomics, although it's probably not widely supported yet.

[Stef O'Rear]

On Wed, Feb 14, 2018 at 5:34 AM, Paul Miranda <paulcm...@gmail.com> wrote:
> There is this line from the riscv-spec: "A simple microarchitecture can
> implement AMOs using the LR/SC primitives."
>
> Which leads me to believe it would be acceptable to implement the atomics
> using reservation-style bus hardware with retry.
> Of course the newer AXI5 supports true atomics, although it's probably not
> widely supported yet.

If you do that, the AMO can't finish until the SC succeeds, and at
that point there is no longer a reservation, so from the programmer's
point of view an AMO does not set a reservation.

-s

[Paul Miranda]

Yes, within one hart, or from U/S/H level if the atomic is implemented with trap to M code.

[Samuel Falvo II]

On Wed, Feb 14, 2018 at 1:53 AM, Xavier <csh9...@gmail.com> wrote:
> Hello Samuel,
>
> Thank you :) The explanation clarifies my confusion.
> However, some bus protocol(ex. AXI4) doesn't support the lock type
> transaction.

The ARLOCK or AWLOCK signal is there to support atomic
read-modify-write transactions. Full AXI4 does support locked
transactions as long as this signal exists on your read or write
channel. Perhaps you're thinking of AXI4-Lite, where it is not
specified.

[Xavier]

Hello Samuel, 

Some information extracted from ARM document. 

-------------------

AXI4 does not support locked transactions. However, an AXI3 implementation must support locked transactions

AXI4 removes support for locked transactions because:

• the majority of components do not require locked transactions

• the implementation of locked transactions has a significant effect on:

— the complexity of the interconnect

— the ability to make QoS guarantees.

-------------------

Samuel Falvo II於 2018年2月14日星期三 UTC+8下午11時59分00秒寫道：

[Xavier]

Hello All,

If bus or memory controller does't support atomic operations, 

I am thinking AMO can be still composed by the LR/SC primitives. But trigger the exception while SC fail. 

Then, the SW handler can take care retry .....

It's an alternative way to achieve the same goal. however, is it compatible with the spec?

Thanks,

Xavier

Xavier於 2018年2月15日星期四 UTC+8上午12時42分42秒寫道：

[Jose Renau]

 I would not use LR/SC in the minions because they will not scale. I would try to find

a way to embed atomics in the AXI4 protocol. We just need to trigger a store (as

the atomic has data) and also trigger a read respose for it like if it were are load.

 Highly scalable atomics would be needed even with software coherence.

--
You received this message because you are subscribed to the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+u...@groups.riscv.org.
To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3ef8eb0e-462f-442e-b41a-fa6f28abb3f7%40groups.riscv.org.

[Paul Miranda]

AXI5 has Atomics, but it's not widely supported yet that I have seen

To unsubscribe from this group and stop receiving emails from it, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/3ef8eb0e-462f-442e-b41a-fa6f28abb3f7%40groups.riscv.org.

--
You received this message because you are subscribed to a topic in the Google Groups "RISC-V ISA Dev" group.
To unsubscribe from this topic, visit https://groups.google.com/a/groups.riscv.org/d/topic/isa-dev/mK671a1Wj08/unsubscribe.
To unsubscribe from this group and all its topics, send an email to isa-dev+unsubscribe@groups.riscv.org.

To post to this group, send email to isa...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/isa-dev/.

To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/isa-dev/em04e96a9b-3b5e-4a85-b6d8-2a646046f460%40desktop-gfmadk4.